AL-Go
AL-Go copied to clipboard
microsoft
Installing dependencies based on the appDependencyProbingPaths setting fail
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
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?
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?
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
Would it be possible to get the .zip file mentioned above to investigate why this fails?
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.
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 GitHubhttps://github.com/microsoft/AL-Go/issues/1067#issuecomment-2125549733, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHQWZMLHTFMSPO3DKSLVRPDZDTTZVAVCNFSM6AAAAABHE7LL26VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRVGU2DSNZTGM. You are receiving this because you authored the thread.Message ID: @.@.>>
New info: If I use powershell instead of pwsh it works (by setting "shell": "powershell" in .AL-Go/settings.json).
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?
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".
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
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.
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.