Installing dependencies based on the appDependencyProbingPaths setting fail

[kennetlindberg]

All builds (I think, at least a bunch of them) that reference other apps using the appDependencyProbingPaths property fail with "Unexpected error when running action. Error Message: Processing data from remote server bc8928362223 failed with the following error message: An internal error occurred".
I've tried it with the latest AL-Go (v5.1) and a brand new build server created using a script that I got from @freddydk.

Logs attached.
logs_23385149816.zip

[kennetlindberg]

This problem persists and several of our pipelines don't work so this is a big issue for us at the moment. Is there any indication on if and when you will be able to take a look at this?

[freddydk]

Sorry about the delay
Looking at the log, I can see:

2024-05-03T05:17:44.6490538Z ##[warning]Some of the release tags cannot be recognized as a semantic version string (https://semver.org). Using default GitHub sorting for releases, which will not work for release branches

It ends up downloading release 4.12 of the bank pro app - is that the right one? (the latest)

These are the version it downloads and tries to publish to a container.

cust-pubsec-main-Apps-21.10.113.0.zip
datalager-connector-main-Apps-19.8.89.0.zip
bank-pro-main-Apps-4.12.1585.0.zip

and it looks like this dependency isn't resolved by any of those:

Consilia Solutions Ab_Public Sector Base_21.4.0.0.app

hence failing installation of Bank Pro.

Does this sound accurate?

[kennetlindberg]

Well, unfortunately no.

"Consilia Solutions Ab_Public Sector Base_21.4.0.0.app" is "cust-pubsec-main-Apps-21.10.113.0.zip" (not the same version but that should not be the problem).

I just ran a build in another repository that has the same issue and fewer dependencies. Attaching logs.

internal-deployer-job-logs.zip

[kennetlindberg]

Here is also the event log.
internal-deployer-main-ContainerEventLog-23.24.86.0.zip

[freddydk]

Would it be possible to get the .zip file mentioned above to investigate why this fails?

[kennetlindberg]

I've sent a zip by e-mail.

[freddydk]

Haven't received anything yet.
Maybe you need to send a URL from where I can download a file - not sure I can receive a .zip file with apps.

[kennetlindberg]

I’ve now sent a download link. Kind regards, Kennet From: Freddy Kristiansen ***@***.***> Sent: onsdag 22 maj 2024 22:04 To: microsoft/AL-Go ***@***.***> Cc: Kennet Lindberg ***@***.***>; Author ***@***.***> Subject: Re: [microsoft/AL-Go] Installing dependencies based on the appDependencyProbingPaths setting fail (Issue #1067) Haven't received anything yet. Maybe you need to send a URL from where I can download a file - not sure I can receive a .zip file with apps. — Reply to this email directly, view it on GitHub<#1067 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AHQWZMLHTFMSPO3DKSLVRPDZDTTZVAVCNFSM6AAAAABHE7LL26VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRVGU2DSNZTGM>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

[kennetlindberg]

New info: If I use powershell instead of pwsh it works (by setting "shell": "powershell" in .AL-Go/settings.json).

[freddydk]

Thanks for this info - will investigate

[freddydk]

@kennetlindberg - could you share the log when running powershell?

[kennetlindberg]

Sure:
logs_24252696341.zip

[freddydk]

There are a lot of other differences in the logs (than pwsh and powershell).
If you change the shell to pwsh - does it then fail again (on the same runners)

To me this looks more like a problem with the self-hosted runners than a problem with pwsh/powershell.

Could you maybe try using windows-latest / pwsh and see whether that fails?

[kennetlindberg]

Hi, here are a few comparable logs (there are no other changes except for the settings tested). They were run on our own server, but this problem started appearing back when we we running on a Azure virtual machine (created with a script I got from you) and also on freshly created runners.

powershell_logs_24377615426.zip
pwsh_logs_24376604210.zip
windows_latest_pwsh_logs_24378110537.zip

The only working one is "powershell".

[freddydk]

Looking at this now - this seems to be a problem in how sessions are created in a container - I know there is a difference in how pwsh and powershell creates sessions in containers - one succeeds, the other one apparently fails.

Quite a few changes went into this area lately - but all should be part of 6.0.18 which you are running here

Will see if I can make a repro

[freddydk]

I am unable to repro the problem here.
I would probably need access to a repo which repros this if I am to investigate further.

[kennetlindberg]

This issue has now disappeared and it works to run without "shell": "powershell" again. Don't know why, but I guess it doesn't matter.