Closed fvet closed 3 years ago
We'll need to repro this scenario to come up with a fix .. working on it!
Did you try with the "nav_artifact_app_filter" param?
(see, this is why we provide previews ;-))
This is why we are testing on a separate branch 😉
@waldo1001
Did you try with the "nav_artifact_app_filter" param?
Not sure how we would use the filter parameter, as this is same problem as in #227
@waldo1001 If no filters are used AlOpsAppSign resolves to the correct app, but immediatly after the resolve, it's fetching the wrong app:
If filters are used for ALOpsAppSign it still resolves to the correct app, but then it tries to fetch app again with applied filter, but in the wrong directory. It seems that resolving the app isn't used for fetching the app to sign:
If I add an additional powershell step to move my apps from ArtifactDirectory to WorkingDirectory it seems that resolve and fetch do result in the same app-file:
@waldo1001 I've seen quit some issues tagged with 'part of upcoming release'. Have you been able to simulate the above? If not, we could try to provide a repro using some dummy ALProjects (Please ping if needed) We're still blocked on signing our apps as part of the pipelines using the native ALOps steps...
Dear @fvet ,
Could you please check this in our latest release v1.438 ?
Kind regards
@AdminHodor As member of @fvet team, I can confirm that this seems to be fixed.
Describe the bug Previous to the ALOpsAppCompiler@2 version, we had setup to compile / sign steps, one for the app and one for the test app. Switching to v2 seems like ALOpsAppCompiler is able to compile both app and test app at once, which is fine!
However, when signing the apps, I'm getting following error
Cannot bind argument to parameter 'Path' because it is null.
It resolves to the test app, while it should in fact Sign both apps. I've default the artifact_path (used to refer to $(System.ArtifactsDirectory))
the used yaml
the output
Compile
Sign