[Enhancement]: workflows/CICD.yaml too restrictive on which branches produce app artifacts

[SteveKrisjanovsD365]

Feature description

Currently the PublishArtifacts logic in unmodified CICD.yaml is as follows for determining which branches generate artifacts:

publishArtifacts: ${{ github.ref_name == 'main' || startswith(github.ref_name, 'release/') || startswith(github.ref_name, 'releases/') || needs.Initialization.outputs.deliveryTargetsJson != '[]' || needs.Initialization.outputs.environmentCount > 0 }}

this presents a problem for our pipelines as we have more than one main branch.

we use [main] for the latest production-ready code for BC24

we also have a [main-2500.100] branch pre-release code targeting BC25

release/* branches aren't suitable as our BC25 code is an ongoing work in progress

this means our only currently option is to customize CICD.yaml to allow branches that match pattern main* (e.g. startswith main). Unfortinately updating the AL go system files wipes out this change.

I reviewed the AL go settings documention and there doesn't appear to be a setting whitelist branches other than main, release/* and releases/*

can this be improved or am I doing something wrong?

[freddydk]

As the matter of fact - the preview version of AL-Go for GitHub has changed this (and this will be in v6.3)
Artifacts will be published by all builds, although artifacts deemed to be shortlived will only have a retention period of one day.
The retention period for shortLivedArtifacts can be changed though, see https://aka.ms/algoreleasenotes

[SteveKrisjanovsD365]

@freddydk that's excellent!

Is there a tentative release date for algo 6.3?

[freddydk]

Probably tomorrow