publish container images to ghcr.io

[kranurag7]

I looked into https://hub.docker.com/r/lycheeverse/lychee/tags and I didn't find any versioning that I can depend on.

I would like to have a container image carrying static lychee executable and whose tag is synced with lychee version released on GitHub. As of now, docker images are not tagged with new lychee version.

For example, we have 0.14.3 tag in GitHub releases but I don't have the image with that tag on DockerHub.

I think, we can create a workflow that will be executable once we cut a new release by pushing a tag. This workflow will build the container image in CI and then push it to ghcr.io or this organization.

Afterwards, we can use the image in a multistage pipeline or even standalone as well (docker run --rm ghcr.io/lycheeverse/lychee .)

I intend to use it in the following manner in a multistage pipeline.

FROM ghcr.io/lycheeverse/lychee:0.14.3 as lychee
COPY --from=lychee /usr/bin/lychee /usr/bin/lychee

Happy to help here.

[mre]

Sorry, I don't understand what's the advantage of ghcr over Dockerhub. Why do we need both?

As of now, docker images are not tagged with new lychee version.
For example, we have 0.14.3 tag in GitHub releases but I don't have the image with that tag on DockerHub.

That's a bug. I think I'm missing the patch directive in the Docker workflow here:

lychee/.github/workflows/docker.yml

Lines 47 to 55 in 13f4339

	type=schedule
	type=ref,event=branch
	type=ref,event=pr
	type=semver,pattern={{version}}
	type=semver,pattern={{major}}.{{minor}}
	type=semver,pattern={{major}}
	type=sha
	# set latest tag for default branch
	type=raw,value=latest,enable={{is_default_branch}}

Maybe that's all it takes to fix it.

I intend to use it in the following manner in a multistage pipeline.

FROM ghcr.io/lycheeverse/lychee:0.14.3 as lychee
COPY --from=lychee /usr/bin/lychee /usr/bin/lychee

This should already be possible (if the tag was available).

/tmp ❯❯❯ cat Dockerfile                                                                                                                                                                                       
FROM debian:latest
COPY --from=lycheeverse/lychee /usr/local/bin/lychee /usr/bin/lychee


/tmp ❯❯❯ docker build --tag foo .
[+] Building 0.6s (8/8) FINISHED  
...
                                                                                                                          
/tmp ❯❯❯ docker run --entrypoint /usr/bin/lychee foo
error: the following required arguments were not provided:
  <inputs>...

Usage: lychee <inputs>...

For more information, try '--help'.

Note that the path to lychee inside the Docker image is
/usr/local/bin/lychee (not /usr/bin/lychee).

[kranurag7]

I don't understand what's the advantage of ghcr over Dockerhub. Why do we need both?

We don't need both for sure, I just wanted to depend on ghcr.io for tagging. If the tagging issue is already solved via DockerHub registry then that will be great.

From a project perspective, using ghcr.io registry will allow everyone to run CI on forks otherwise, in current context, I've to change the name of the image in workflow file.
In case of ghcr.io we can use github.actor and more variables related to GitHub.
But I also don't want the project to maintain images in two registries so I'll tagging issue will solve the problem completely.

[mre]

0.14.3 is out now. I retriggered the pipeline. Don't know why it wasn't triggered before, but it wasn't the tagging. That part works. So we just need to keep an eye out for the next release. Maybe I'm missing a trigger somewhere.

As you said, maintaining two registries would cause some overhead, so I'd prefer to avoid that. 😉

With that, I think we can close this.

[kranurag7]

@mre @thomas-zahner Thank you for the new release.
I think images for v0.15.0 is missing in the registry.

On DockerHub, I can see that we have latest, master, latest-alpine, master-alpine tag but not the semver tag that one can track with ongoing releases.

I'll take a more deeper look into the pipeline during the weekend and see if I can fix it if it's not fixed already.

[mre]

@kranurag7, sure, let's look into it. Could you create a new issue, though, as this one is closed? 🙂