Fully support sha pinning + remove docker from runtime.

[Icantjuddle]

Summary / Background

I noticed that pinning to an arbitrary commit actually runs with the latest version always since it pulls the latest docker image. I also saw some failures in reaching ghcr.io at times and wanted to see if I could try to remove network dependencies from the action.

Since this is a standard go binary with few external dependencies it seemed like it could run directly on the github action runner without an intermediate container. Dropping the docker runtime also allows it to run on the newer + cheaper ubuntu-slim runner type.

This is a bit of an experiment of what changing those might look like.
Instead of using a docker image, this PR changes release and runtime to:

During release:

• builds the binary in prepare-release, then embeds the shasums in the release itself

When running a released tag or sha

• Has release version + checksums already baked in
• Downloads the release version by tag
• Verifies against built-in shasums
• Caches

When running against arbitrary non-released commit

• Release version + checksums are unset
• Sets up go
• builds code
• Caches

This has a few benefits:

• Ensures that pinning any sha gets you the action as-of that sha.
• Speeds up action by downloading fewer dependencies.
• Ensures end-to-end checksum integrity. If a user pins to a release sha, they will only run a single built version of the tool, cannot be changed by compromise or re-tagging a release since shas are baked into the commit.

This has a few costs as well:

• Release and runtime code is a bit more complicated.

Wanted to use this as a way of opening a conversation as to what this could look like and see if you have any interest.
Totally understand if you don't want to change the release/runtime process.

[gemini-code-assist]

Code Review

This pull request transitions the GitHub Action from a Docker-based action to a composite action. It introduces scripts to resolve, download, cache, or build the codeowners-plus binary from source, embedding checksums in action.yml during release preparation. Feedback on the new scripts highlights several improvements: implementing a trap in action-ensure.sh to clean up temporary files, removing the non-portable --quiet flag from sha256sum commands to ensure compatibility with BusyBox/Alpine environments, and resolving the output path to an absolute path in build-action-binary.sh to prevent issues when changing directories.

[BakerNet]

@Icantjuddle Thank you for bringing the SHA pinning issue to my attention and I appreciate the experiment PR as well. I agree with the general premise of being runnable outside Docker, and really only used Docker initially for simplicity.

I pushed a few commits the branch. I tried to strip a lot of the complexity out from the original PR so that:

• Uses goreleaser for the action binary as well
• Utilizes the goreleaser checksums instead of embedding SHA
• Has a single install-action.sh script instead of multiple scripts

I'll enable Immutable releases now that they're GA so that the checksums.txt can be trusted as well. Embedding the SHA kind of makes sense when immutable releases aren't enabled but with immutable releases using a checksum file is sufficient.

Let me know if you have any concerns or want to push back on any of the changes I pushed.

[Icantjuddle]

Thanks for taking a look.

I didn't know about immutable releases, enabling them really helps reduce the jank needed as it no longer needs to deal with release<->tag mismatch.

Only 2 notes, one repeated flags and the other on not caching builds-from-source. I think the latter is the more impactful.

[Icantjuddle]

This is why I made short build script to avoid duplicating the flags here; doesn't really matter to me though.

[Icantjuddle]

I think caching after having built from source is the most impactful time to cache. Otherwise non-release shas need to build everytime.