Don't use link to latest stable release for nightly

[eread]

Don't use link to latest stable release for nightly.

[eread]

@mre @thomas-zahner Could you review this one?

I think when LYCHEE_VERSION is set to nightly in a job (like here: https://github.com/lycheeverse/lychee/actions/runs/17020826384/job/48249611607#step:10:221), that the expectation would be that the job would make use of the nightly release (https://github.com/lycheeverse/lychee/releases/tag/nightly) rather than the latest stable (currently https://github.com/lycheeverse/lychee/releases/tag/lychee-v0.19.1).

The latest stable doesn't yet have lychee-aarch64-unknown-linux-musl.tar.gz but when it does, we could direct the Dockerfile to use latest stable when LYCHEE_VERSION is set to latest (which is what happens if LYCHEE_VERSION is unset). For now, it works to use the nightly version for both LYCHEE_VERSION=nightly and LYCHEE_VERSION=latest because the nightly has lychee-aarch64-unknown-linux-musl.tar.gz.

WDYT?

[mre]

Have you double-checked that the URL structure is indeed different?

So:

• https://github.com/lycheeverse/lychee/releases/latest/download
• https://github.com/lycheeverse/lychee/releases/download/nightly

I'm not quite sure where that difference comes from.

[mre]

Just saw your other comment here, which means you probably tested it locally and it worked. Still confused why the URL-structure is different. Is it a GitHub quirk or what am I missing here? 🤔

[eread]

@mre I was initially confused too!

https://github.com/lycheeverse/lychee/releases/latest/download redirects to https://github.com/lycheeverse/lychee/releases/download/lychee-v0.19.1 at the moment. When the filename is appended, you end up with (for example) https://github.com/lycheeverse/lychee/releases/latest/download/lychee-aarch64-unknown-linux-gnu.tar.gz redirecting to https://github.com/lycheeverse/lychee/releases/download/lychee-v0.19.1/lychee-aarch64-unknown-linux-gnu.tar.gz.

https://github.com/lycheeverse/lychee/releases/download/nightly doesn't redirect. So when the filename is appended, you end up with https://github.com/lycheeverse/lychee/releases/download/nightly/lychee-aarch64-unknown-linux-gnu.tar.gz, which I think is a better choice.

[eread]

The short version of my comment here: #1802 (comment) is that:

• This doesn't exist: https://github.com/lycheeverse/lychee/releases/latest/download/lychee-aarch64-unknown-linux-musl.tar.gz
• This does exist: https://github.com/lycheeverse/lychee/releases/download/nightly/lychee-aarch64-unknown-linux-musl.tar.gz

So, when the next release is cut and has a lychee-aarch64-unknown-linux-musl.tar.gz for the latest stable version, the existing configuration in this project will start working (and you shouldn't have these failures: https://github.com/lycheeverse/lychee/actions/runs/17020826384/job/48249611607#step:10:355).

But it occurred to me, @mre, that you might prefer the behavior introduced by this PR.

[thomas-zahner]

@eread @mre For your info: I've released v0.20.0 but the docker build step still fails. I didn't investigate the problem myself yet. Maybe the CI logs contain new information as someone mentioned with a new release the step might work again. Or would this PR potentially resolve the issue?

[eread]

@eread @mre For your info: I've released v0.20.0 but the docker build step still fails. I didn't investigate the problem myself yet. Maybe the CI logs contain new information as someone mentioned with a new release the step might work again. Or would this PR potentially resolve the issue?

@thomas-zahner Thanks for releasing that!

The command that's being run is at: https://github.com/lycheeverse/lychee/actions/runs/17148270680/job/48648658034#step:9:218. I note that LYCHEE_VERSION is being specified as latest there.

When I run a cut-down version of the command locally (docker buildx build --build-arg LYCHEE_VERSION=latest --file Dockerfile-CI.Dockerfile .), it works. It pulls https://github.com/lycheeverse/lychee/releases/download/lychee-v0.20.0/lychee-aarch64-unknown-linux-gnu.tar.gz, which exists.

So I wonder if it's a timing issue. Perhaps the tar.gz file didn't exist when this was run - is the order of jobs the problem?

Interestingly, this PR would change that behaviour. It seems like the project does expect latest to be latest stable, and not the same as nightly. So this PR would need some more refactoring.

When I run a similar command for the Alpine-based Dockerfile (docker buildx build --build-arg LYCHEE_VERSION=latest --file Dockerfile-CI.alpine.Dockerfile .), it also works. It's pulling https://github.com/lycheeverse/lychee/releases/download/lychee-v0.20.0/lychee-aarch64-unknown-linux-musl.tar.gz.

So it does seem like if those jobs could run again, they'd work? 🤔

[thomas-zahner]

You are right, this is a timing issue. I've reran the job and it passed now 👍

One thing I notice is that docker images are not tagged with any version numbers, e.g. 0.20.0. In the past this was done as there are images tagged 0.15.0. This is not directly related to the issue and PR but it still something that would be nice to add again at some point.

[eread]

You are right, this is a timing issue. I've reran the job and it passed now 👍

One thing I notice is that docker images are not tagged with any version numbers, e.g. 0.20.0. In the past this was done as there are images tagged 0.15.0. This is not directly related to the issue and PR but it still something that would be nice to add again at some point.

@thomas-zahner There hasn't been tagged Docker images since the move to https://github.com/release-plz/release-plz in this project. A few attempts have been made to get that to work again.

It we look at this job :https://github.com/lycheeverse/lychee/actions/runs/17137903575/job/48618381985#step:9:220, we can see the image is tagged with: lycheeverse/lychee:pr-1808 and lycheeverse/lychee:sha-5c3f7ac. However, we're not pushing them.

So two outstanding issues I think:

• When a release PR is merged, tag with release version as well as (or instead of) these other tags.
• When a release PR is merged, add --push to the build command.
• When a release PR is merged, run Docker image builds after the binaries are uploaded, not before.

Tagging and pushing is already working elsewhere, and so is the order of operations presumably. There must still be old release logic in the configuration.

CC @mre

[eread]

@thomas-zahner @mre Ok, I've refactored this one.

Basically, in the context of a call to docker build, if:

• LYCHEE_VERSION=latest, use special URL https://github.com/lycheeverse/lychee/releases/latest/download. So for example at the moment, https://github.com/lycheeverse/lychee/releases/latest/download/lychee-aarch64-unknown-linux-gnu.tar.gz redirects to https://github.com/lycheeverse/lychee/releases/download/lychee-v0.20.0/lychee-aarch64-unknown-linux-gnu.tar.gz.
• LYCHEE_VERSION=nightly, use regular URL https://github.com/lycheeverse/lychee/releases/download/nightly. So https://github.com/lycheeverse/lychee/releases/download/nightly/lychee-aarch64-unknown-linux-gnu.tar.gz resolves.
• LYCHEE_VERSION=<tagged release>, use regular URL such as https://github.com/lycheeverse/lychee/releases/download/lychee-v0.20.0. So if LYCHEE_VERSION=lychee-v0.20.0, then https://github.com/lycheeverse/lychee/releases/download/lychee-v0.20.0/lychee-aarch64-unknown-linux-gnu.tar.gz resolves.

I haven't yet seen a call to docker build that uses LYCHEE_VERSION=<tagged release>, but it would be possible some time I guess.

To make wget's behaviour more obvious, I've added a second commit to this pull request to make it more verbose.

WDYT?

[mre]

Make sense to me.

[mre]

Thanks for the thorough analysis, @eread.

[eread]

You are right, this is a timing issue. I've reran the job and it passed now 👍
One thing I notice is that docker images are not tagged with any version numbers, e.g. 0.20.0. In the past this was done as there are images tagged 0.15.0. This is not directly related to the issue and PR but it still something that would be nice to add again at some point.

@thomas-zahner There hasn't been tagged Docker images since the move to https://github.com/release-plz/release-plz in this project. A few attempts have been made to get that to work again.

It we look at this job :https://github.com/lycheeverse/lychee/actions/runs/17137903575/job/48618381985#step:9:220, we can see the image is tagged with: lycheeverse/lychee:pr-1808 and lycheeverse/lychee:sha-5c3f7ac. However, we're not pushing them.

So two outstanding issues I think:

• When a release PR is merged, tag with release version as well as (or instead of) these other tags.
• When a release PR is merged, add --push to the build command.
• When a release PR is merged, run Docker image builds after the binaries are uploaded, not before.

Tagging and pushing is already working elsewhere, and so is the order of operations presumably. There must still be old release logic in the configuration.

CC @mre

@trask You've worked on some of this for this project in the past (for example: #1738). Any thoughts?