A critical limitation of the first design was the assumption that there would only be one Docker build per commit. As such, software packages were often only refreshed when Zephyr was upgraded.
This new design opens the door to better CI practices. It allows regular rebuilds of the Docker images irrespective of version control. This is critical for incorporating the latest security fixes and bug patches as soon as possible.
Maintainers are still required to trigger stable releases (via tags), but this can be revisited in the future if further automation is necessary.
PR: #50
Pre-builds the dev-generic stage and provides it to all subsequent jobs. This improves the integrity between the jobs within a particular workflow run, especially in the absence of registry credentials. It also reduces the workflow run duration when building multiple architectures in parallel.
PR: #61
Runs a set of tests before the candidate image can be pushed. The tests aim to cover all common use cases.
It was not possible to run the tests as a separate set of jobs because `actions/upload-artifact` and `actions/download-artifact` are too slow. Moreover, a separate set of jobs would create a bottleneck because some architectures complete their docker builds faster than others.
The custom docker shell may require maintenance if GitHub change the underlying runner environment in the future. It doesn't (yet?) support multi-line run commands.
PR: #46
This is a simpler and cleaner approach than previous implementations.
PR: #49
See: 7b71139613414351ccf293331201b6d19fb93d16
See: 40f6d7bf50372132159779cc6af7e7374fd87ab7
Further testing has suggested that GitHub Actions sanitizes any secrets in job outputs. The namespace definitions must therefore be duplicated across each job that needs them.
PR: #47
See: b65d7974a2e0c25212db727431dac2eea01ddcdd
See: 7cf9196c14336e847280732821b69c057d9704bf
The original design assumed that every user would configure login credentials with appropriate write permissions for the Docker Hub repository. Consequently, forks or pull requests fail on the first step.
This change allows the build to complete without login credentials. It skips pushing the cache or pushing the candidate image.
The release (docker tag) step still requires login credentials and fails if they are absent. This guarantees that git tagging is only possible once all images have been pushed out to all container registries.
PR: #24
Lets the workflow run without specifying the `DOCKER_HUB_NAMESPACE` secret. It uses `github.repository_owner` as the default value for the Docker Hub namespace.
PR: #23
Defining the LABEL via an ARG at the top of the Dockerfile prevents other GitHub repositories (or local Docker users) from leveraging otherwise identical cache layers.
PR: #18
