waldo1001
commented
7 months ago I think BCCH has a problem processing the license like this.
licensefile: '\bbb.bclicense'
Can you try either:
- not providing a license
- full path to it
- download link
Closed stefanJeady closed 6 months ago
waldo1001
commented
7 months ago I think BCCH has a problem processing the license like this.
licensefile: '\bbb.bclicense'
Can you try either:
stefanJeady
commented
7 months ago Removing the license file from this step allowed it to continue. The path was already the full path as the file was in working dir, before the last few runs this always worked. Using blob storage with a direct SAS URI I got the error could not resolve accountnamehere.windows.net
Also likely related but technically another issue that started at the same time as this:
It looks like something changed with BC 23.2 all our pipelines above this version with the same ymal and comit version as pervious suscessful runs now fail on compile app reading settings .json (there is no issue reading app.json a few lines prior)
If I run the same pipeline with 23.0 it works without issue.
*** Loading Json Object: [c:\Run\DevOps\APS_Core_BC\.vscode\settings.json]
##[error]Exception calling ".ctor" with "1" argument(s): "Invalid URI: The format of the URI could not be determined."
Async Command Start: Add Build Tag
Build '399' has following tags now: AL.Compiler.ALLanguage, BC.Platform.23.0.15817.0, BC.Version.23.4.15643.15915, myimage-sandbox-23.4.15643.15915-nz-10.0.20348.2227-ltsc2022
Async Command End: Add Build Tag```
JeremyVyska
commented
7 months ago @waldo1001 - I'm running into the same Exception problem:
` VSCode Settings: [c:\Run\DevOps\SpareBrainedLicensing_APP.vscode\settings.json] VSCode-Settings json found. *** Loading Json Object: [c:\Run\DevOps\SpareBrainedLicensing_APP.vscode\settings.json]
Async Command Start: Add Build Tag `
This only started happening when I added a relative path ruleset to the settings.json.
We've tried both:
"al.ruleSetPath": "src\\.rulesets\\SPBLicensing.ruleset.json"
and
"al.ruleSetPath": "src/.rulesets/SPBLicensing.ruleset.json"
This src folder is in repo/[AppFolderName]/src so I'm wondering if it's an issue with it being in a subfolder. The weird thing is, I have a different app still built against v22 with the same folder structure and ruleset handling. This one I'm building now is against v23 latest.
JanBoes
commented
7 months ago We have the same issue. After removing the settings.json file everything worked fine. And we also use relative path to our ruleset as JermemyVyska is mentioning.
settings.json:
{
"al.ruleSetPath": "MBS.ruleset.json",
"al.codeAnalyzers": [
"${CodeCop}",
"${UICop}"
],
"CRS.FileNamePattern": "<ObjectNameShort>.<ObjectTypeShortPascalCase>.al",
"CRS.FileNamePatternExtensions": "<ObjectNameShort>.<ObjectTypeShortPascalCase>.al",
"CRS.FileNamePatternPageCustomizations": "<ObjectNameShort>.<ObjectTypeShortPascalCase>.al",
"CRS.OnSaveAlFileAction": "Rename",
"CRS.ObjectNamePrefix": "INB ",
"CRS.RemovePrefixFromFilename": true,
"alOutline.fixCodeCopMissingParenthesesOnSave": true
}@waldo1001 Is there an update for this?
waldo1001
commented
7 months ago We didn't have time to look into this.
Doesn't really sound like a blocking issue as it should be possible to work with a full path / download link (the latter being best practice anyway)?
JanBoes
commented
7 months ago Hi @waldo1001
Sorry but I find a blocking issue as we have to remove our settings.json to be able to run a successful pipeline.
waldo1001
commented
7 months ago Ok, it seems I misunderstood .. sorry.
Can anyone send me a repro (a (simple) yaml that fails) for the ruleset-issue? That seems ALOps-related.
waldo1001
commented
7 months ago yaml:
subfolder ruleset:
settings.json:
Using ruleset:
So I need that repro, I'm afraid .. it's a bit searching in the dark now ..
JeremyVyska
commented
7 months ago I wonder if the ./ at the start is the secret sauce there, or if it's specifically only with multi-root apps.
We had tried "al.ruleSetPath": "src/.rulesets/MainThing.ruleset.json"
In our case, the repo has
MainThing_APP MainThing_TEST
as two apps in the base of the repo. Within the MainThing_APP, we have the folders like
[Repo]/MainThing_APP/src/.rulesets/MainThing.ruleset.json
So, what works fine in VSC is that the [Repo]/MainThing_APP/.vscode/settings.json has the path as relative to the MainThing_APP/ root, rather than the repo root. My hunch is that is the distinction.
I can try to whip up a simple repro-repo tomorrow?
waldo1001
commented
7 months ago We also have 2 apps: App & Test.
Rulesets are here: App/.codeAnalysis/app.ruleset.json Test/.codeAnalysis/app.ruleset.json
Settings are here: App/.vscode/settings.json Test/.vscode/settings.json
So pretty similar to yours.
Would be awesome to receive a repro
JeremyVyska
commented
7 months ago OK, just was testing this live with @alphakintari :
Yep. it's all pathing issues.
To have a 'relative' to the app path, you have to start with ./
So, for example, if you had:
src/.rulesets/ALOpsIssue722.ruleset.json
This works fine in VSC, but will cause an error in ALOps pipelines.
We updated it to:
./src/.rulesets/ALOpsIssue722.ruleset.json
And it powered right through. So, relative-to-the-app can work, but you have to give it that specific "root hint" at the start.
waldo1001
commented
7 months ago @stefanJeady , did you try ´./bbb.bclicense´
waldo1001
commented
6 months ago @stefanJeady , I'll close the issue. Please reopen when still not working for you.
Describe the bug Create Docker Install Failed
the used yaml
the output
Expected behavior Install without error after install CRONUS.
Additional context Using the latest version of BCCH.