fix initial run of release-check workflow

[marten-seemann]

When we first deploy this workflow, we're adding the version.json file. For this PR, we don't want to run the release-check workflow, as a release for this version number already exists.

Tested on the testing branch. Since this is a called workflow, we don't have run a new deployment to roll out this fix :)

[marten-seemann]

It's really annoying that there's no way to exit early from a GH Actions workflow (without failing the workflow run).

[mvdan]

I wonder if you could split this workflow into two jobs; have the second job depend on the first one, and only run if INITIAL_RUN==true.

[mvdan]

To some degree, we could consider the same for COMPARE_TO.

[mvdan]

Hmm, I think in a previous PR I had suggested to use underscores to make env var names like COMPARETO easier to read. Maybe that slipped through the cracks :)

[marten-seemann]

I wonder if you could split this workflow into two jobs; have the second job depend on the first one, and only run if INITIAL_RUN==true.

That comes at the expense of booting up two runners, checking out the repo twice and passing around env.VERSION. I still hope that GitHub gives us a way to cleanly do an early exit from workflows :)

Hmm, I think in a previous PR I had suggested to use underscores to make env var names like COMPARETO easier to read. Maybe that slipped through the cracks :)

I remember making that change, but it must have gotten swallowed by git at some point. Sorry.

[marten-seemann]

The logic in the original PR was wrong. In order to determine if this is the initial run of a workflow, we can't only look if version.json was added. That's a required condition, but not sufficient:
Imagine that we're cutting a new release on a release branch that doesn't yet have a version.json. In order to cut the release, we'd create the version.json with the new version number. We still should run the release-check workflow in this case.

I fixed the logic by checking that in addition to version.json being added we also use a version number for which a git tag already exists.

[mvdan]

I wonder if you could split this workflow into two jobs; have the second job depend on the first one, and only run if INITIAL_RUN==true.

[mvdan]

To some degree, we could consider the same for COMPARE_TO.

[mvdan]

Hmm, I think in a previous PR I had suggested to use underscores to make env var names like COMPARETO easier to read. Maybe that slipped through the cracks :)