Switch to Docker-based builds and releases#57
Conversation
Signed-off-by: Travis Raines <571832+rainest@users.noreply.github.com>
Add A Docker-based build and release job. This uses an upstream workflow along with a multi-stage Dockerfile to build an image with the ref's binary. If triggered via PR or push to main, this pushes a pre-release image to the registry. If triggered via tag, this pushes a release image and creates a Github release. Signed-off-by: Travis Raines <571832+rainest@users.noreply.github.com>
|
Is there a limiting technical reason we can't do this with Goreleaser? Goreleaser has sort of become the de facto standard for release builds. |
Yes and no. There's a paywall reason that blocks the good technical solution, and the bad technical solutions are bad. There was some discussion between Alex, Broadwing, and I in the PCS is, as mentioned, a good lighthouse candidate because it's where we tested previously for the Docker stuff, and because its #48 never got off the ground. If that works well here, I'm looking at moving to this as the de facto standard, because it can do everything we need from GoReleaser, as well as things that GoReleaser doesn't let you do without a pro submission, and makes the "build local Docker image from completely unpushed code" workflow less something that requires some undocumented This is a bit of competing UX between stuff LANL knows and works for them and stuff that I know and have demonstrated has parity and beyond parity, such is OSS: people will suggest alternatives and make a case for them. |
|
|
||
| CMD /usr/local/bin/power-control | ||
|
|
||
| ENTRYPOINT ["/sbin/tini", "--"] |
There was a problem hiding this comment.
Why do we need another Dockerfile?
There was a problem hiding this comment.
To build a real tall stack of em. We've got so many, we may as well continue and build a Dockerfile staircase to the moon.
This is another instance of existing stuff left in place pending full vet of the new system, to leave an easy revert path if I screwed up something major. Eventually, I expect to replace the existing Dockerfile contents with the contents of Dockerfile.build.
I can possibly merge Dockerfile.debug into it as well, since it was separate for similar "doesn't work with the GoReleaser-style 'binary comes from a mystery black box prior to docker build' pipeline" reasons.
The test ones will have to remain separate AFAIK.
|
@rainest Thanks for the info. I wasn't aware of that context. |
3 participants
Summary and Scope
This disables the GoReleaser release and adds a new Docker-based release. The Docker-based release also handles pushing pre-release images.
This includes an atypical setup where there are two jobs, because the ARM build requires the special
to make Kafka libs happy.
Putting this in place so that we can create preview images of #56 for LANL to test with.
Testing
Testing mostly in the prior PR to add the upstream workflow: OpenCHAMI/github-actions#5
This PR includes some cleanup to TODOs and uses proper releases instead of my test fork, but should otherwise match the fork/upstream action testing from that PR.
Risks and Mitigations
If this breaks, we can't release, and will need to revert to the GoReleaser action. If everything's fine after a few releases, we can go ahead and prune the GoReleaser workflow from this entirely, instead of just no-oping it.