[Bug]: Publish To Environment fails with "The remote server returned an error: (401) Unauthorized. Unauthorized"

[BW-PA]

AL-Go version

8.0

Describe the issue

I will preface this report that I'm not sure if this is an AL-Go Documentation issue or a BcContainerHelper issue.

I have an AppSource app that I wanted to deploy to a Sandbox environment from within AL-Go and so followed the guide here https://github.com/microsoft/AL-Go/blob/main/Scenarios/RegisterSandboxEnvironment.md

I followed all the steps in that guide, which can be summarised as

1. Create App Registration
2. Create App Registration Secret
3. Add API permissions
4. Add App Registration Client ID to Entra Apps page in the BC environment I am deploying to.
5. Create Environment Secret in GitHub Repo with AuthContext
6. Run AL-Go Publish to Environment action.

However, when Running the Publish to Environment action it consistently failed with
Error: Deploying to SandboxAUv27 failed. The remote server returned an error: (401) Unauthorized. Unauthorized

I won't include ALL the things I tried to get this going and instead will short cut to the end.

It was eventually resolved by including the following API permission in my App Registration

And then making sure my App Registration was also added to the Micrsoft Entra Apps page of my tenant in BS Admin Center.

These additional steps are not listed in any of the support documents or AL-Go Scenarios that I could find.

BUT why did it break at all? In theory it doesn't need Admin Center API permissions, as I am deploying direct to the environment and not going anywhere near BC Admin Center.

Well as it turns out, in my situation, not quite.

My app is an AppSource app with a dependency on another AppSource app (both my own). Due to this dependency the Publish to Environment action elects to source the dependent app from AppSource instead of using the appDependencyProbingPaths setting in .AL-Go/settings.json.

Consequently, it calls the BcContainerHelper module Install-BcAppFromAppSource which internally calls Get-BcEnvironments which queries the BC Admin Center for a list of environments. And without my App Registration granted permission in BC Admin Center, it fails with The remote server returned an error: (401) Unauthorized. Unauthorized.

Which raise the following 2 questions.

1. Why does AL-Go opt to install an AppSource dependency from AppSource instead of utilising the appDependencyProbingPaths setting in .AL-Go/settings.json.?
2. Why, after specifying the environment to connect to, does Install-BcAppFromAppSource powershell module need to query the list of environments at all?

Expected behavior

I was expecting AL-Go to utilise the appDependencyProbingPaths property to source the artifact to install into the environment. It does this correctly when building the app via CI/CD workflow. Perhaps it was my misunderstanding that led me to thinking that "Publish To Environment" workflow would behave the same way.

I am also expecting that the error returned in the workflow run would be more helpful. As it is, it just says there was an error. There was no indication about what service was rejecting the authorisation. Without that information, I assumed (incorrectly) I had configured my app registration or BC Entra App page incorrectly.

Steps to reproduce

Once I figured out where the permissions were failing, it was relatively easy to isolate and reproduce the problem directly in PowerShell.

Follow the steps outlined here https://github.com/microsoft/AL-Go/blob/main/Scenarios/RegisterSandboxEnvironment.md

Then using those details, plug the value into the below powershell and run to get the same error.

$authcontext = New-BcAuthContext `
 -clientID '<Client ID>' `
 -clientSecret '<Client Secret>' `
 -tenantID '<BC Tenant>' 


Install-BcAppFromAppSource `
    -appId '<Any BC AppSource App ID>' `
    -bcAuthContext $authcontext `
    -environment '<BC Environment Name>' 

After getting the error, go back to app registration and add AdminCenter.ReadWrite.All permission

Then add the Application (Client) ID to the Microsoft Entra Apps page in BC Admin Center

Then when you re-run the powershell. It will succeed. At this point (assuming AL-Go app is using the same App Registration details and environment), it too will succeed.

Additional context (logs, screenshots, etc.)

Here are the logs of the failed run for reference.
logs_49270650009.zip

URL to failed run
https://github.com/BW-PA/AppSourceApp1/actions/runs/19130334193/job/54669380974#step:7:71

Here are the Public Repos I setup to reproduce the issue prior to figuring out how to reproduce via powershell directly. 1 is the primary app and has a dependency on 2. Note that neither are actually live on AppSource. So once the (401) Unauthorized error is resolved it gets App not found on AppSource error (which is expected)

1. https://github.com/BW-PA/AppSourceApp1
2. https://github.com/BW-PA/AppSourceApp1Common

[mazhelez]

Hi @BW-PA
Thank you for the thorough analysis, it really helped me understand the essence of the issue.

To your questions:

Why does AL-Go opt to install an AppSource dependency from AppSource instead of utilising the appDependencyProbingPaths setting in .AL-Go/settings.json.?

This is because AL-Go doesn't expose the dependencies by default. Besides, the apps in the appProbingPaths settings could be symbols-only, so they cannot be published.
If you set the generateDependencyArtifact setting to true, then the CICD will produce another artifact that holds the dependencies (the same, that were used when building the apps). Moreover, it will use the dependency apps in this artifact during deployment, not try installing them from App Source.

Why, after specifying the environment to connect to, does Install-BcAppFromAppSource powershell module need to query the list of environments at all?

As far as I can tell from the implementation, it's because there are some verification steps. Definitely, a BCContainerHelper issue with Install-BcAppFromAppSource

[BW-PA]

Hi @mazhelez,

I had looked at the generateDependencyArtifact setting and attempted both with it enabled and disabled.

Moreover, it will use the dependency apps in this artifact during deployment, not try installing them from App Source.

Your description is what I was expecting to happen too. So I went back to my sample repos

https://github.com/BW-PA/AppSourceApp1
https://github.com/BW-PA/AppSourceApp1Common

And checked that I had it enabled. AppSourceApp1/.AL-Go/settings.json contains

  "generateDependencyArtifact": true,
  "appDependencyProbingPaths":  [
        {
            "repo": "https://github.com/BW-PA/AppSourceApp1Common",
            "version": "latest",
            "release_status": "release",
            "projects": "*"
        }
    ]

And when I run the Publish to Environment it appears it is still trying to run Install-BCAppFromAppSource.

Attached are the full log outputs from that failed run

logs_49710804409.zip

And I think the reason for the 400 Bad request error is due to neither of these sample apps being published on AppSource, so it couldn't find it to install. Which further adds weight to generateDependencyArtifact = true not sourcing the artifact from the repo and attempting to install it from AppSource

[mazhelez]

Ahh, I see what I missed. It's indeed installing the dependencies from App Source.

But why is AppSourceApp1Common installed on the sandbox in the first place? As a mitigation, you can try to publish/install it from its own repository.

[BW-PA]

I'm not sure I understand the question.

AppSourceApp1Common is being installed to the sandbox because AppSourceApp1 has it as a dependency and I am trying to publish AppSourceApp1 to the sandbox.

Installing AppSourceApp1Common to the sandbox prior to running the Publish To Environment on AppSourceApp1 works because the dependency is already present and so it doesn't attempt to install it.

Does that answer your question?

[mazhelez]

Yes. That is indeed what I meant.

If the AppSourceApp1Common app is in another repository, you need to run "Publish to Environment" there prior to running the same action in the repository where AppSourceApp1 app is located.

[BW-PA]

Just confirming that yes, if you deploy the common, dependency app from its own repo first, then the app with the dependency in it 2nd, everything works because it checks if the common app is installed in the environment, finds it, and so doesn't attempt to install it from AppSource.

Is my understanding of the purpose of appDependencyProbingPaths correct as documented here https://github.com/microsoft/AL-Go/blob/main/Scenarios/AppDependencies.md

Does appDependencyProbingPaths apply only to building apps alone and not deploying them to an environment.
OR
Does appDependencyProbingPaths apply to both building and deploying to environments too?

[mazhelez]

Apps from appDependencyProbingPaths and other ways for specifying dependencies may be included in the deployment (if GenerateDependencyArtifact is true).

The peculiarity of your case is that the dependency is an AppSource app. And dependencies from App Source are always installed from App Source.