Version numbers/identifiers for Docker image tags

[felixfontein]

It would be nice if there would be some kind of version numbers or identifiers for Pebble which can be used to identify specific versions, for example for tags in the official Pebble repository (https://hub.docker.com/r/letsencrypt/pebble/tags/). Having only latest is not so useful if you want to target a specific version :-)

Ideas for version identifiers:

• commit IDs (the ones from master) (I'm using that right now for a ACME testing container);
• dates (version is built from the latest commit to master on that day);
• some integer or "regular" version number (which someone has to increment for every commit/set of commits which should define a new version). This requires manual work (or some clever scripting, with storing the version number somewhere).

I think I'd prefer the first solution, since it is the simplest to implement. Any suggestions/thoughts/ideas?

[cpu]

We use the second date-based option for Boulder's docker image tags. I'd be slightly in favour of that for consistency's sake.

[felixfontein]

Considering the amount of commits Pebble has, this is essentially equivalent to master's HEAD ;-)

Would every day get a new date tag, or would only days when new commits are added get a new date tag?

[cpu]

or would only days when new commits are added get a new date tag?

Only days where new commits were added. I think Pebble's commit volume is pretty low.

[cpu]

I haven't been able to figure out how to get Dockerhub autobuilds working for a public repo in the Let's Encrypt organization. I must be missing something silly but it only ever shows me repositories from my own Github account.

In the meantime I pushed a letsencrypt/pebble:2018-07-20 tag to Dockerhub for the current master (dac33b8)

[ldez]

@cpu You need to create the repo like that:

[cpu]

@ldez That's the section of DockerHub I've been interacting with (following the instructions here: https://docs.docker.com/docker-hub/github/)

After clicking the "Create Automated Build" I land on this screen:

Choosing the Github option then brings me to a page where I can see my own linked Github account's repositories:

Despite being a member of the Let's Encrypt organization (I seem to have admin rights on our org's repos in Dockerhub) it doesn't show anything but my own personal repositories. E.g. I can't select this github.com/letsencrypt/pebble repository.

Am I doing something silly? The DockerHub "LetsEncrypt" organization predates me. Maybe there are account credentials for it that could be used to log in to the dockerhub that I should be using instead?

[cpu]

Aha! I read the docs a second time and I think this might be the catch I'm missing: https://docs.docker.com/docker-hub/github/#github-organizations

I'll investigate and see if our GH org admin needs to activate this.

[ldez]

Docker hub have a bug to refresh repositories.
Try to logout/login.

[ldez]

Sorry try to Unlink Github -> link to Github your Docker account.

[cpu]

@ldez I'm 100% stumped. I've unlinked and relinked my Github several times (and also logged in/out of Dockerhub) with no results.

I added the "Docker" service to the repo (despite the deprecation warnings), and it shows a "green" status:

I also had a Github org admin for the "letsencrypt" org check the org perms and they indicated there doesn't seem to be anything missing.

Despite all of the above I still can only see my own repositories when following the instructions for creating an auto-build with Dockerhub. Pretty frustrating!

I'm open to suggestions. I must be missing something....

[ldez]

As you can see I can access to the repositories of an organization.

To be sure:

• From Docker Hub: Unlink Github -> link to Github

Do you have the "good" rights on the https://hub.docker.com/u/letsencrypt/ organization?

[cpu]

As you see I can access to the repositories of an organization.

Very strange. I see what you mean but the Let's Encrypt organization doesn't show up for me in "Users/Organizations"

To be sure: From Docker Hub: Unlink Github -> link to Github

Yup! Tried that several times now, also making sure to revoke from the Github side.

Do you have the "good" rights on the https://hub.docker.com/u/letsencrypt/ organization?

As far as I know. I'm able to edit the DockerHub organization settings. I was also able to create the "letsencrypt/pebble" repository: https://hub.docker.com/r/letsencrypt/pebble/

[cpu]

I haven't had a chance to try and take another crack at auto-builds. In the meantime I'll push new tags when master changes manually 😭

[shred]

Could you add a 'latest' tag to pebble and pebble-challtestsrv? I would like to use the official docker images instead of my selfmade ones. However, with the release dates only, I'd have to change my build script on every pebble update. 😉 Thank you!

[cpu]

There's now a nice PR from @ldez that will add Docker image auto-publishing if its merged. I think this is a good time to revisit the discussion about what kind of versioning system folks would like to see Pebble use before I go ahead and merge it.

Historically I matched Boulder's approach and published date based tags (2019-01-04, 2018-12-14, etc). The approach proposed in #187 will switch to having three sets of tags:

1. latest - the latest build
2. commit hash: each commit have an image
3. tag: each tag have an image

I think having an image per-commit hash is perhaps overkill but the having a latest image and an image per tag seems uncontroversial.

I think the only remaining question from my perspective is whether I should be creating the date based tags still or switch to something more formal like semantic versioning and push tags like 0.0.1, 0.0.2, 0.1.0, etc.

@felixfontein @ldez @shred You folks are the only consumers of the Pebble images I can tag off-hand. What are your preferences? I'm slightly in favour of dropping the "date" tags and using semver.

@jsha @rolandshoemaker Do you two have any opinions here?

Thanks all! (Especially @ldez for writing #187!)

[shred]

Personally I would prefer semver. The commit hash would be fine too, and would also mean less work for you. But since I am going to use the latest tag anyway, I don't have a strong oppinion on that.

[ldez]

I agree with @shred and I will also use latest.

So your choice will be best 😸

[ldez]

I forgot something:

• in Lego, I will use latest because I want to detect new features/fixes as soon as possible
• in Traefik, I will use a "stable" version, because I don't want to failed on features/fixes that are not available in the LE production

[felixfontein]

I can't use latest (for reproducibility); both dates and semver are fine for me. Personally, I'd also prefer semver though (as opposed to dates, it is possible to have two different versions on one day ;-) ).

[jsha]

Semver is great!

[ldez]

I propose to update my PR like that:

• latest: the latest tagged version
• tag: each tag have an image
• no image per commit hash

Are you agree?

[cpu]

@ldez Yes that sounds great.

It sounds like everyone is comfortable with semver so we'll go that direction for making tags/releases 👍 Thanks!

[cpu]

This is all wrapped up now 🎉 I released a v1.0.0 and a v1.0.1 today (https://github.com/letsencrypt/pebble/releases/). There's a latest tag in Dockerhub for both pebble and pebble-challtestsrv as well as images for the v1.0.1 release tag (I will backfill v1.0.0 images later).