"Create Release" Workflow for multi-project repos

[SteveKrisjanovsD365]

Many of the AL-Go repos support project-specific workflows (e.g. increment version, publish to appsource, etc) but the "Create Release" workflow is applied to all projects in the repository.

to support project-specific releases, I'm considering naming and tagging the release (versioningstrategy=3) as "x.y.z-" so we don't run into ambiguity/conflict issues with the release tags.

There are edge cases where one project is release-ready in the [main] branch but another project is not and still in WIP development. Currently however the release will indlude all projects/apps in the repository.

currently, my thought process is to remove any non-release-ready app artifacts from the release after the release is created (I'm not sure however if this is a best practice or not).

would it not make sense to have a prompt in the "Create Release" workflow to specify a comma-delimited list of projects to include in the release build?

e.g. if I have a repo project structure as follows:

• org_name/repo_name
  • Project-App1
  • Project-App2

if I specify to only build the release for Project1-App1, al-go would only build the release artifacts for that project and omit Project-App2 from the release

thoughts??

[freddydk]

Note that creating a release doesn't build anything - it just promotes an existing build to a release.

A release is a GitHub construct - and you release what's in a repository - you cannot release part of a repository.
General recommendation is that all apps in an AL-Go Project are installed together and all apps/projects in a repository are released together.

[SteveKrisjanovsD365]

Fair enough. I'm aware the release workflow doesn't "build" anything I just worded my question wrong. My bad.

My bigger issue is each project can potentially have its own semantic version (the "increment version" workflow can be applied to some or all projects in a repo)

This makes it awkward to leverage the "create release" workflow since the release tag MUST be a single semantic version (not sure if that's an algo requirment or a GitHub one) which gets messy if each project has a different x.y.z (we use versioningstrategy=3). Thoughts?

Maybe allowing project specific versioning isn't a good match for the release workflow?

[SteveKrisjanovsD365]

In case you're wondering why all our apps in the repo aren't release-ready.

One repo we have six apps. Four of them have been promoted to appsource since late 2024. Two remaining apps for our Australian localizations haven't been published to appsource yet since they're in active development.

So when a release is finished, I ammend the release comments to mention our AU apps are not yet release ready to avoid confusion

[freddydk]

In that case, you should switch to multi-repository AL-Go.
If you go to your GitHub repo - you will find releases (on the right hand side) - that will give you a list of releases from this repo.
It would be strange to have to scroll down to find specific projects etc in the list of releases.

GitHub is not designed for your idea and neither is AL-Go

[SteveKrisjanovsD365]

If that's the case (note I'm not against the idea of moving to one app per repo but I need to discuss it with my team), I guess I'm grappling with understanding the benefits of a multi-project repo if each project can potentially have its own distinct versioning but GitHub releases (especially with algo's enforcement of a single semantic version for the release tag) doesn't support this, especially if one or more projects in a repository are not release ready.

We do have one library appsource app, but it sits in its own dedicated repository since it'll be ultimately a root-level dependency amongst all our PTE and appsource apps.

Currently we have two major multi-project repositories. One for our appsource apps and one for our family of PTE apps