Fix docker tagging for release versions

[trask]

I hope will resolve #1628

This is the relevant part of the workflow to understand what's going on:

lychee/.github/workflows/docker.yml

Lines 46 to 48 in 3592972

	type=semver,pattern={{version}},value=${{ github.ref_name }},prefix=lychee-
	type=semver,pattern={{major}}.{{minor}},value=${{ github.ref_name }},prefix=lychee-
	type=semver,pattern={{major}},value=${{ github.ref_name }},prefix=lychee-

This is configuring docker/metadata-action.

And type=semver

Will be used on a push tag event and requires a valid semver Git tag

Even if docker/metadata-action is being used on branch push, I think that ${{ github.ref_name }} is the branch name when the workflow is triggered by a branch push (and the tag name when the workflow is triggered by a tag push).

[mre]

Thanks, this should ensure that the Docker build runs after release-plz has finished (which is necessary because it depends on the release binaries).

Looks good to me.

[eread]

Thanks, this should ensure that the Docker build runs after release-plz has finished (which is necessary because it depends on the release binaries).

Looks good to me.

@trask @mre @thomas-zahner If I'm not mistaken, this is the Docker workflow run that happened when the lychee-v0.20.1 Git tag was pushed: https://github.com/lycheeverse/lychee/actions/runs/17205362504.

On the plus side, the Docker command was run with push, so it would've created new Docker images if it had succeeded.

On the down side:

• The command didn't have a Docker image tag for 0.20.1, only for the SHA: https://github.com/lycheeverse/lychee/actions/runs/17205362504/job/48804656733#step:9:218
• It looks like wget couldn't find the correct binary yet: https://github.com/lycheeverse/lychee/actions/runs/17205362504/job/48804656733#step:9:427. I guess that means having a tag doesn't mean having a binary yet?

This PR removed workflow_run, which means it no longer waits for a successful run of "Release Binary" workflow? Should it? Would that work given Release Binary seems to be failing a lot: https://github.com/lycheeverse/lychee/actions/workflows/release-binary.yml.

[mre]

Yeah, you're right, just because we have a tag doesn't mean with have the release binaries. That has been haunting us for quite a while. Thats' also why workflow_run is not a solution. Perhaps we can do a super simple thing and wait until the binaries get built with a bash script?

- name: Login to DockerHub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      - name: Wait for binary release
        if: ${{ (github.event_name != 'pull_request' &&
                 github.actor != 'dependabot[bot]') ||
                 startsWith(github.ref, 'lychee-v') }}
        run: |
          LYCHEE_VERSION="${{ github.ref == 'refs/heads/master' && 'nightly' || 'latest' }}"
          
          BASE_URL=$(case "$LYCHEE_VERSION" in
            "latest" | "nightly") echo "https://github.com/lycheeverse/lychee/releases/latest/download";;
            *) echo "https://github.com/lycheeverse/lychee/releases/download/$LYCHEE_VERSION";;
          esac)
          
          X86_URL="${BASE_URL}/lychee-x86_64-unknown-linux-gnu.tar.gz"
          ARM_URL="${BASE_URL}/lychee-aarch64-unknown-linux-gnu.tar.gz"
          
          echo "Waiting for both binaries to be available..."
          
          while true; do
            if curl -sSf --head "$X86_URL" >/dev/null 2>&1 && curl -sSf --head "$ARM_URL" >/dev/null 2>&1; then
              echo "Both binaries ready!"
              break
            fi
            sleep 20
          done

      - name: Push Image (debian)
        uses: docker/build-push-action@v6
        # ... rest of your existing config

I haven't tested this, but that's my best guess. Either way, I think we should move this discussion into a follow-up issue. @eread, are you up for that?

[eread]

I haven't tested this, but that's my best guess. Either way, I think we should move this discussion into a follow-up issue. @eread, are you up for that?

Not sure about that solution. I guess if it had a maximum number of iterations (rather than an infinite number), it might work ok. It's a shame that wget and curl both seem to regard a 404 as a fatal error that can't be retried.

On the first issue (no release tag), I've raised: #1833. Given the actions seem to be able to be run manually (so someone can manually intervene when they fail to find a release binary and retry later), I thought the issue of no release tag was more important.