We edit the release to be latest as the last step in the Release job.

I think this means that early exit here makes this job only continue if that last step succeeded in setting the release with the pushed tag as latest, but one of the gh actions post steps failed at the end of the job. Even if those happened, the resulting artifacts exist and are valid, right?

If that's true, I wonder if this revert-latest job is worth maintaining.

Maybe it would be cleaner to mark the release as latest in a separate gh action job in this same workflow, with a needs condition.

Then, it would only be eligible to run once Release has completed all steps and post-steps successfully. I expect that this would also handle cancellation of the job, which so far hasn't been handled with the if: failure() condition.

eg:

  mark-latest:
    needs: Release
    runs-on: ubuntu-latest
    steps:
      - run: gh release edit "$TAG" --latest
        env:
          GH_TOKEN: ${{ github.token }}
          GH_REPO: ${{ github.repository }}
          TAG: ${{ github.ref_name }}

You're right. TBH, this whole release workflow makes me a little itchy. GoReleaser has already promoted the package, image, and brew tap. I wonder why we have make_release: false in .goreleaser.yml... ah, it's because goreleaser tags the release as latest before any artifacts get uploaded. Lovely.

I guess we can do a post-step after cleanup, but I definitely want to add more helpful error messaging around this. We have a lot of ways to end up in an intermediate release state here.