[Question]: Workflow skips deliverytoAppsource

[ismailhafid1]

Question

following the documentation for signing an application and publishing the same application on Appsource , we managed to deliver the app to appsource for the first time using workflows .

but after the first delivery , the workflows started to ignore the delivery to Appsource . the following screenshots shows the configuration : the screenshot above shows the secrets that will help us to connect between Azure and Github and using the script that links between Azure and Github we get a successful authentication to Azure : and for the settings Files in Github Folder and AlGo Folder :

but the workflow ignore the delivertoappsource , any idea where the problem is coming from ?

[freddydk]

Could you supply the full log of the CI/CD ignoring deliver to appsource?

[ismailhafid1]

@freddydk i sent you the log file via Email . Thank you

[freddydk]

You have a secret called ACCEPT_INSIDEREULA, set to the value true.

This makes GitHub think that the string true is a secret and will mask this from the output and prevent GitHub actions from using the value true from one job to the other.

You will probably see warnings in the build explaining that some outputs contains secrets and are ignored.

Obviously, the value true or false cannot be secrets - and this breaks AL-Go for GitHub (and many other GitHub actions as well).

So, remove the ACCEPT_INSIDEREULA secret and your workflow will probably work again.

BTW - why did you create this secret? What instructed you in doing this? (we might need to fix some docs).

Also - the insiderSasToken secret is no longer used (your build probably shows warnings with this as well) and you are running AL-Go v5.0 (your build also shows warnings about this).

[ismailhafid1]

Thanks for the fast reply , about why i created the ACCEPT_INSIDEREULA , it wasn't me and I looked in the documentation there was no mention of this secret , once i have an answer about this , i will email you the details . about the issue : i removed the ACCEPT_INSIDEREULA secret as you said , but it ignores the deliver to appsource , i had a global variable that had DeliverToStorage and i removed it too and ran the workflow , but sadly it keeps ignoring the deliver to appsource . i sent you the new workflow log file via email.

[freddydk]

Just now noticed that you are running an older version of AL-Go - v5.0 Your workflow will be telling you that updates are available - and if you run Update AL-Go System Files to the latest version - it should work. The reason is that the deliverToAppSource setting was introduced in v5.1 (see https://github.com/microsoft/AL-Go/blob/main/RELEASENOTES.md#v51) - before that, a different setting was controlling the continuous delivery.

[ismailhafid1]

thanks for the reply , it worked and deliver to appsource triggred after the build. but now my issue is the workflow returned : Error Message: The remote server returned an error: (401) Unauthorized. Unauthorized , do i need to have some specific permissions in Partner Center for my account to complete the delivery workflow ?

[freddydk]

It sounds like you didn't go through the steps outlined here: https://github.com/microsoft/AL-Go/blob/main/Scenarios/PublishToAppSource.md - especially step 1 from this: https://learn.microsoft.com/en-us/partner-center/marketplace-offers/azure-app-apis

[ismailhafid1]

Thanks for the reply @freddydk , i spent these 2 days trying to find where i can modify the Authentication to uses for my appsource app ,since we are using 2 appsource apps for the same Entra app i tought that the second appsource app will follow the same delivery steps as the first appsource app because the first one uses user_impersonation which works perfectly but the second one uses S2S and uses clientcredentials , where can i modify the settings that defines which authentication to use for the delivery ?

[freddydk]

The method is determined by the authcontext secret. If the AppSourceContext secret contains clientId+clientSecret - it uses S2S If the AppSourceContext secret contains a refreshtoken - is uses impersonation

[ismailhafid1]

is there some specific permission in partner center that i need to have to get the authContext from partner center ? do these steps need to be done for user-impersonation too ? because the documentation only mentions this in the S2S

[freddydk]

1. No, you don't need to register a Microsoft Entra App in partner center if you are not using a Microsoft Entra App for authentication.

2. On the error - did you try using the value for scopes shown in the red error?

3. During your devicelogin - are you using the user, who has permissions to partner center to login with?

4. You mentioned that you already have one AppSource App, where authentication works with user impersonation? doesn't anybody know how this was setup? (the user impersonation authcontext needs to be renewed every 90 days or so).

[ismailhafid1]

i used the same Scope but i keep getting the same error . i m using an account who has permissions to partner center with the enough permissions. the person who made the setup is on vacation , my account and his have the same permissions , he used the same script for the user-impersonation and got the refresh token , but i don't have the value of this refresh token to use it in APPSOURCECONTEXT for the second app , is there a way to have more info about 401 unauthorized ? an info that shows what exacly am i missing to access Partner Center via the script , does ingestion API have a specific permission that needs to be granted for my account ?

[freddydk]

Nope - 401 means that you are authenticated, but you are doing something you don't have access to. Looks like you will have to wait for the other person to get back from vacation and submit manually until then