Switch to shared workflow

[taylorludwig]

Summary and Scope

Similar to OpenCHAMI/cloud-init#82

Uses the new re-usable workflow for goreleaser builds

Testing

No changes to code itself only the build workflow.
All previous build logic is preserved

PR creation should trigger a snapshot build.

[rainest]

Alas, the DCO complains at us all.

This shouldn't run on pull_request, should it?

The other one doesn't run on PR, and we'll have a bunch of PRs where we don't need an image available outside of ephemeral CI images. Dispatch can handle ones where we do want an image for external testing.

I'm not actually sure about dispatch either at present--the cloud-init history indicates it did at least run there, but IDK how it's separating runs that only build an image versus those that release, or how it's tagging the PR images.

Tagged packages appears to only have release versions, are the PR images going into the untagged set?

I don't love that our Dockerfiles require a build beforehand rather than being able to handle it on their own; IDK if there's a way to handle that and have whatever cake goreleaser provides us too. We should ideally have something that runs locally, to build images prior to a complete PR, and I don't think we have goreleaser properly configured/documented for that.

[synackd]

I don't love that our Dockerfiles require a build beforehand rather than being able to handle it on their own; IDK if there's a way to handle that and have whatever cake goreleaser provides us too. We should ideally have something that runs locally, to build images prior to a complete PR, and I don't think we have goreleaser properly configured/documented for that.

I don't love this either, especially since it doesn't seem that Goreleaser allows a way to build a local container for a single architecture outside of modifying .goreleaser.yaml; however, having a binary to pass into the container is what Goreleaser expects since it builds the binary. We used to have a Makefile in services for easily building things locally, but having multiple ways of building is not ideal from a maintenance/troubleshooting perspective. Goreleaser is fine as a CI tool but, in my experience, is clunky as a local build tool, especially for building containers. I'd love to find a solution that doesn't involve modifying the .goreleaser.yaml file for local builds/tests.

[taylorludwig]

This shouldn't run on pull_request, should it?

So actually this new re-usable build and release workflow is smart enough that it only does a full release on builds run from a v* tag.

We keep the on: pull_request to validate goreleaser builds work correctly with a --snapshot build. This triggers the goreleaser build to validate everything builds correctly with goreleaser but doesn't create a release or push the images.

I just pushed a new commit that I'm hoping fixes the error about The workflow is requesting permissions ... but is only allowed 'actions: no[...]. Not sure why we need to explicitly grant permissions in this workflow when we didn't need to in the cloud-init one. Or maybe its because @alexlovelltroy created that PR and mine needs approval to run?

[rainest]

It may be the repo. Our org versus repo-local settings are still a bit of a mess depending on when a repo was created, and unfortunately I can't see for this one.

From chat, the job performing different-ish functions under the same name is rather confusing. If it's the same workflow and choosing different behavior internally, I'd like to have separately-named invocations even if it costs some boilerplate duplication--the workflow definitions on the consumer side are at least short.

Alternately, what all are we trying to catch with a full build? go vet results won't necessarily catch everything, but it'll probably catch most build failure problems that don't stem from changes to CI config.

[taylorludwig]

Looks like attest binary failed too now with Error: Failed to get ID token: Error message: Unable to get ACTIONS_ID_TOKEN_REQUEST_URL env variable

I'll close this for now and we can re-evaluate in chat on how we want to split up the build and release steps. I'll also do some more testing with to track down the above error in a forked repo where I trigger the builds.