Release step runner binaries
Problem
In order to run the step runner in a customer's execution environment, such as the Docker image supplied in a GitLab CI/CD job, the step runner must compiled and released as a binary.
Proposal
- Step runner is versioned using Semantic Versioning. Initially, the major version should remain at
0
. - The Step runner has a changelog. (suggest: manual changelog with merge=union, or Git trailer changelog)
- Step runner should be built as a Docker image that supports multiple architectures (TBD). Each image should include a statically linked step runner binary that is compiled to the specific architecture.
- The final stage in the
main
branch step runner pipeline contains a release job. The job can only be triggered by maintainers of step runner and should act as a "one-click release". - The release job creates a Git tag, a GitLab release, and tags the previously built Docker image with
latest
,MAJOR
,MAJOR.MINOR
,MAJOR.MINOR.PATCH
. The tagged image should support multiple architectures. - The release job should fail if the Git tag that would be created already exists.
Example

Out of scope
Subsequent issues will download the released binary for installation into the customer's execution environment.
Edited by Cameron Swords