DRY out the GitHub Actions Configuration

[QuintillusCFC]

Our Windows, Linux, and Mac build steps are about 83% shared (based on comparing them with KDiff and visually estimating the percentage). However, they're all rewritten from scratch. The more that is added to them, the more the overhead is noticeable, and the more tools like KDiff are needed to ensure we don't fat-finger something.

This is not great. We should try to DRY out the configuration.

After some DuckDuckGo'ing and Googling, I think the best option may be Composite Actions.

StackOverflow on the topic: https://stackoverflow.com/questions/59757355/reuse-portion-of-github-action-across-jobs The 3rd answer, by Cardinal, has a nice breakdown of the options and relative advantages. I'm pretty sure we don't want reusable workflows, as we only want parts of the workflows (steps) to be reusable. Strategies miiiight work but I'm not sure we have quite enough shared. Composite Actions seem like the right balance.

Blog post on the topic: https://colinsalmcorner.com/github-composite-actions/ Uses this GitHub repo as reference: https://github.com/dotnet-architecture/eShopOnContainers/tree/dev/.github/workflows And this commit shows exactly what happens when you add Composite Actions. Look at basket-api.yml and .github/workflows/composite/build/action.yml in particular.

[QuintillusCFC]

Other options include:

• Using something other than GitHub that makes it easier to compose actions. BitBucket makes this very easy. I remember figuring out how to do it with CircleCI as well, maybe not quite as easy as BitBucket, but much easier than here. Downside: Probably harder to trigger it based on commits/etc. - but we aren't doing that yet.
• Running the build for all the platforms within one job. Most of the 83% that's shared is at the beginning, so we could probably just do that first, and then sequentially build for each platform. Downside: Would take longer to do it sequentially (although a lot of the time is the container setup so maybe not tons more time. But this isn't super time critical anyway.

For now I'm seeing if Composite Actions solve the problem, but if they aren't looking good for some reason, these are good alternatives.

[QuintillusCFC]

Container initialization + checkout is 50-55 seconds of usually 90-100 overall. So the sequential option would add 70-100 seconds. Not the end of the world.

CompositeActions still under test, for some reason you have to specify the shell for each step. It definitely doesn't feel like as mature of a product as the competitors I've used in that category.

[QuintillusCFC]

Oh, it could tell I was getting impatient with it, the build in progress as I wrote that succeeded. Noice! Now to look at the diff...

[QuintillusCFC]

One of the disadvantages of the CompositeAction is it doesn't break down steps as much in the GUI. From before:

From after:

Do we care about those being printed out though? Probably not. We can still see the logs if they fail and we need to debug them.

Still trying to figure out how to avoid setting the shell for each step. Also considering just getting rid of the steps altogether, their main purpose is printing out here and if they aren't going to, the only point is documentation. Which can be done via comments or echo statements, no need to put step names. The echos would also still show up in the logs, so maybe that's the better option...