Split build from publish and test

[freddydk]

Summary

Today, the build step in AL-Go is done using Run-AlPipeline from BcContainerHelper.
Run-AlPipeline will build, sign, publish and run tests.
for Performance reasons and due to new code signing requirements, this process needs to change.

1. Building the apps should be done first
2. Then Signing
3. Then publishing and running tests.

Only step 3 requires an actual BC instance (Container or like).
Building and signing can be much faster using this approach.

Additionally refactor the build part of workflows to use an composite action, to capture the build parts in one area.

Current structure:

New structure (single project):

New Structure (multi-project):

It should also be possible run the p1 tests together with the p2 tests to validate that p2 didn't break p1 tests.

Success Criteria

TBD

Implementation

TBD

Try it out

Not yet available

[fvet]

@freddydk I see this is labelled '2024 w1' (although draft PR pending). Can we expect this as part of the April release?
Not having to spin up a container for building apps would certainly decrease our build time.

[freddydk]

Nope - not going to make it - will have to go through the plan and adjust, sorry

[mazhelez]

Splitting the build and test jobs is possible even today by splitting the apps into different AL-Go projects.

Of course, that way apps and test apps will be in different artifacts for delivery/deployment. So, I believe we'll try another approach: having the ability to bundle apps from different AL-Go projects together.

[fvet]

I'm not quite sure if I follow the suggested solution, but our goal is to keep to one repository, containing all apps, so we can deploy / release them all together as one solution, similar to how the MS multi-app repo's are structured.

[freddydk]

We will document ways of doing this as part of #1331