Allow workflows to build on specific branches/commits
ianpittwood opened this issue · comments
Github Actions are stateful so when we run a build it will use the Dockerfile definitions on the branch/commit we're on. Using workflow_dispatch and some configuration on @actions/checkout we can run a workflow definition on one branch against the Dockerfiles on another. This should give us better control over builds for dev-product branches and rebuilds/patches on previous versions.
One limit to this is that if the build scripts are decoupled from the source, and the base image is decoupled from the product content, they can break in incompatible ways. For example, if the justfile in the source code has some command, abc, and that command is changed to def, or perhaps its default argument changes, then you won't be able to build the code this way. You'd have to branch off of an older point, before the incompatible change to build scripts.
This gives us better flexibility over adding build matrix configurations that can then apply retroactively to old product releases, but I'm not sure how it helps us with patch releases.
Decoupling the workflow from the source code is a good idea in general, but I don't think it's a magic bullet on our patch release issues. I think of the ultimate solution as the combination of:
- independent workflow that allow specification somehow of:
- base image content/version
- product installation content. This is the folder or repo for each product.
- separate verification process that ties together all products at specific versions, and runs tests
If we have this, then we have the ability to vary any part of the stack and test/release any combination.