Create an automated build of this project on Docker Hub

[tadas-subonis]

I would love to run these utils using `docker run -it --rm .... " so I wouldn't need to install it.

[rhatdan]

So you want to run skopeo from a container? Other tools?

[jlsalmon]

We have containerised CI jobs that use skopeo to move images around. For now I'm having to build an image manually - it would be really useful to be able to docker run projectatomic/skopeo 👼

Looks like projectatomic has lots of automated builds on docker hub already?

[rhatdan]

Now if you had said podman run projectatomic/skopeo , you would have made me really happy. I am not sure who is in charge of these images on Docker hub. @lsm5 Do you know?

[lsm5]

@scollier do you own projectatomic account on docker hub?

[lsm5]

hmm i think @scollier owns the fedora account but not projectatomic on docker hub, @cgwalters any idea?

[rhatdan]

@TomSweeneyRedHat Now that we have buildah in a container could you look into packageing up skopeo in quay as well?

[TomSweeneyRedHat]

@rhatdan, I was thinking about Podman, but will add skopeo too. I'll first swing by your office early next week to talk over some admin stuff about this with you.

[TomSweeneyRedHat]

Related to #594

[jonaskello]

Any news on this?

[mtrmac]

@TomSweeneyRedHat has been working on this, per #930 ; at least one of the repositories already exists.

[TomSweeneyRedHat]

We don't have them out on DockerHub, but they are out at quay.io, we just finished putting the last pieces together this morning.

podman run -it --rm quay.io/skopeo/stable:latest -h
podman run -it --rm quay.io/containers/skopeo:latest -h

These are equivalent images, using the same Dockerfile to build them at each location. It uses Fedora and the latest released version of Skopeo. They are built every time a PR is merged into Skopeo's master branch in GitHub.

If you want to try out the testing or the upstream versions, you can instead use:

podman run -it --rm quay.io/skopeo/testing:latest -h
podman run -it --rm quay.io/skopeo/upstream:latest -h

Where testing has the latest version in updates-testing for Fedora and upstream has the latest bits merged into Skopeo's GitHub repo. Both of these are also rebuilt when a PR is merged into the Skopeo master branch on GitHub.

More info and the Dockerfiles that build them at: https://github.com/containers/skopeo/tree/master/contrib/skopeoimage

ps, they work with Docker too if you prefer.

[jonaskello]

@TomSweeneyRedHat Nice work! :-)

I am looking to use skopeo in a GitLab CI build where each build step is based on an image. For this scenario it is nice to have repeatable builds so mutable tags like latest that can point to different images at different points in time is not really suitable. Would it be possible to do immutable tags like 0.4.0 etc. so a tag is guaranteed to point to the same image regardless of point in time? If this is something you would consider I could open a separate issue for that.

[TomSweeneyRedHat]

@jonaskello already there! At least in quay.io/containers/skopeo

# podman run -it --rm quay.io/containers/skopeo list-tags docker://quay.io/containers/skopeo
{
    "Repository": "quay.io/containers/skopeo",
    "Tags": [
        "v0.1.42-dev",
        "master",
        "latest"
    ]
}

I thought I'd one in quay.io/skopeo/stable too, but I did not. I've just repushed one there. So the plan is for both the quay.io/skopeo/stable and quay.io/containers/skopeo, we'll keep refreshing the latest tag as noted prior, and when we get a stable release, I'll capture one of those and push one with the version number as a tag. v1.0.0 has not yet made it completely through the testing process, once it does I'll add a tag for it for both of those repositories.

I will not be adding a similar tag to the upstream or testing repos, those will just have master and latest.