Release process: discrepencies between go install @tag and tag releases

[asraa]

Because go proxy will force immutability on tags, there are times when go install slsa-verifier@TAG mismatches the TAG.

Unfrotuntely, I did this for v1.4.0: I had drafted a pre-release, and found that the SLSA releaser configuration was incorrect, and had to make some fixes to find that out.

In hindsight, maybe instead of drafting a pre-release with this full tag, I should have defined v1.4.0-rc, and ensured that example-package would not have iterated over this (I did make sure to skip over pre-releases now).

Is there anything to do about this now? Or just going forward we'll make sure there's consistency?

[laurentsimon]

and ensured that example-package would not have iterated over this

what do you mean?

let's make sure we do it properly going forward. Shall we update the RELEASE.md?

Would bumping the version (and possibly deleting the problematic one) have helped?

If we start with v1.4.0-rc, how do we rename it for the actual release?

[ianlewis]

and ensured that example-package would not have iterated over this

what do you mean?

let's make sure we do it properly going forward. Shall we update the RELEASE.md?

Would bumping the version (and possibly deleting the problematic one) have helped?

If we start with v1.4.0-rc, how do we rename it for the actual release?

The e2e tests loop over the releases of slsa-verifier to make sure all the past releases work but we used to include pre-releases in those checks. @asraa made sure we don't do that anymore.

The downside is that we don't run that check before releasing so yeah, it should probably be part of our release doc. @asraa had a good reason for suggesting the -rc tag but I must admit I can't remember what it was :-p

[asraa]

. @asraa had a good reason for suggesting the -rc tag but I must admit I can't remember what it was :-p

The reason was because of the provenance / build failure! So I could tag the release on GitHub, but then the provenance generation would fail. This would mean that the go mod would end up pinned, but because the provenance failed I could no longer generate valid provenance at the same SHA (since config for the provenance / build would change the source SHA)

If we start with v1.4.0-rc, how do we rename it for the actual release?

We'd create a new one: the -rc is essentially a "dry-run"

[asraa]

The downside is that we don't run that check before releasing so yeah, it should probably be part of our release doc.

I originally thought that because we run at main, that we "should" always be fine for a release, but there's going to be some change between the last e2e test and changes in verifier. If we use -rc WITHOUT pre-release, this would allow us to wait a day for e2e tests to pick up the release, and we can then tag the actual release.

I think that would solve both the tagging problem here and the smoke test that verifier release will work with the builders.

[laurentsimon]

get it. Makes sense. I got confused by the term "e2e tests". I think of the tests in example-packages for these. I think of e2e tests in the slsa-verifier as the "CLI/main tests".