Allow Docker pushes on release branches

[eread]

As outlined in #1432 (comment), the current workflow won't push to the Docker registry when a release is cut because releases now include a pull request.

This pull request increases the number of conditions under which a Docker image can be pushed.

Closes #1432.

[eread]

@mre Could you review? Do you know if this will work as I've updated it here?

Otherwise, it might be possible in a separate step to include the new logic, and set an environment variable to true and then use that environment variable as the value of push.

WDYT?

[mre]

Looks good, but is the ref_name for release-plz documented somewhere? I was wondering if we should check for a tag name instead. 🤔

[eread]

@mre It's documented here: https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#github-context, but taking a closer look, it might not work for a pull request.

[eread]

@mre I've refactored this pull request. WDYT?

[eread]

@mre Did you want me to ask another maintainer to review?

[mre]

Oh, sorry for dropping the ball on this. 😅

[mre]

Thanks for your contribution (and your patience), @eread. 🥳
Let's see if it works. 🤞

[eread]

Thanks for your contribution (and your patience), @eread. 🥳 Let's see if it works. 🤞

Thanks for the merge @mre! I didn't see an easy way test it for sure. Hopefully a new release isn't too far away 😄

[eread]

@mre @thomas-zahner We got a run of the new logic: https://github.com/lycheeverse/lychee/actions/runs/12389086296/job/34581417146

It looks like push still evaluated to false.

Also, the Docker command was run with --tag lycheeverse/lychee:pr-1554 --tag lycheeverse/lychee:sha-007d93a, rather than --tag lycheeverse/lychee:0.18.0. So still more to do there. 🤔

[eread]

@mre @thomas-zahner We got a run of the new logic: https://github.com/lycheeverse/lychee/actions/runs/12389086296/job/34581417146

It looks like push still evaluated to false.

Also, the Docker command was run with --tag lycheeverse/lychee:pr-1554 --tag lycheeverse/lychee:sha-007d93a, rather than --tag lycheeverse/lychee:0.18.0. So still more to do there. 🤔

@trask I don't suppose you know how to resolve this?

[mre]

The tags are because the pipeline didn't run on a release. The version tag is missing.

So either we're not listening to the right event or the logs belong to a different pipeline run.

[mre]

Yeah, so we don't trigger a pull request on releases.

Typically this is done with

on:
  release:
    types: [published]

However, in our case we have a wait until the release binaries are created; otherwise the build would fail.

I don't know if there's a way to say that the workflow depends on another one. Alternatively, we could just have a "wait" step in the pipeline, which tries to curl the binary every 30 seconds or so until it succeeds.

[mre]

We could trigger on release as shown above and use an action like https://github.com/marketplace/actions/wait-on to wait until the binaries were created.

[eread]

Yeah, so we don't trigger a pull request on releases.

Typically this is done with

on:
  release:
    types: [published]

However, in our case we have a wait until the release binaries are created; otherwise the build would fail.

I don't know if there's a way to say that the workflow depends on another one. Alternatively, we could just have a "wait" step in the pipeline, which tries to curl the binary every 30 seconds or so until it succeeds.

@mre I must've misunderstood how these work: #1598. I guess the release is created when this is merged, and so the release isn't in the context of the pull request anymore.

[eread]

@mre It looks like you can make jobs depend on each other with needs: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds

[eread]

We could trigger on release as shown above and use an action like https://github.com/marketplace/actions/wait-on to wait until the binaries were created.

@mre What about running when a tag is pushed: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onpushbranchestagsbranches-ignoretags-ignore?

[eread]

We could trigger on release as shown above and use an action like https://github.com/marketplace/actions/wait-on to wait until the binaries were created.

@mre What about running when a tag is pushed: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onpushbranchestagsbranches-ignoretags-ignore?

@mre Or maybe we should remove this "escape early" configuration:

lychee/.github/workflows/docker.yml

Line 31 in fc006bd

- name: Exit early if tag and not from release workflow

?

[mre]

Hum, I'm not sure why that was there. I removed it.. Thanks for the idea. We can give it another try on the next release.

[mre]

@mre It looks like you can make jobs depend on each other with needs: docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds

needs is just for expressing dependencies between jobs, not workflows. For that, you'd use workflows. In our case, we already do that. See here.