Publishing of docker images

[victorb]

Currently on Docker Hub, we publish latest builds as :master instead of Docker common practice which is :latest. Would be good to at least update latest as well on new version.

Another good tag to have is stable as right now, master is pointing to a RC version while latest points to an old version.

Structure would be something like this:

• master/latest -> latest shine bleeding-edge build, RCs and so on
• stable -> latest stable version, right now that would be 0.4.9

[skorokithakis]

Agreed, I have been having trouble with this. Should there also be per-version tags?

[Kubuxu]

There is stable image built from release branch and tagged release, last time the release branch was not updated to contain 0.4.9 which is a mistake.

[skorokithakis]

@Kubuxu Yes, it seems that release contains 0.4.8, which is breaking a bunch of my stuff now :(

[ghost]

Yeeah we forgot pushing to the release branch for 0.4.9, doing now

[skorokithakis]

Great, thank you!

[ghost]

@victorbjelkholm we've had the following structure since the beginning:

• latest: current release
• release: current release
• master: current master HEAD

Any strong reason to change that?

[skorokithakis]

Not to speak for him, but I think Victor's point was more "let's make sure that the tags are always updated" rather than to mandate a tag scheme, really, and I would +1 that.

For me, any scheme is fine, as long as it's consistently kept up to date.

[ghost]

It's already in the release checklist, it was apparantly just forgotten for 0.4.9 :)

[skorokithakis]

Ah, great. For me, the biggest UX failure was that search engines return a different Docker repo first, so that led to much confusion for me. If that one can either be removed or at least changed to a note that says "please use this new one", it would save people lots of pain.

[ghost]

Oh mh, the jbenet/go-ipfs image... I've never quite figured out how to properly mirror the ipfs/go-ipfs builds to jbenet/go-ipfs...

[skorokithakis]

I don't think you need to mirror (and probably shouldn't), just change the Readme there to the text "please use this other repo" and a link. That would mostly solve the issue, I think.

[ghost]

The idea was to leave existing scripts and deployments working. With just a changed readme, nobody actually notices. We need to either continue maintaining it (preferred), or delete it.

[skorokithakis]

That makes sense, but I don't know about nobody noticing. I typed "ipfs docker" and went to that repo, if the README was different, I would have just gone to the right one immediately afterwards. Besides, it can't hurt to try.

[victorb]

@victorbjelkholm we've had the following structure since the beginning:
latest: current release
release: current release
master: current master HEAD
Any strong reason to change that?

Well, depending on if "current release" refers to current stable release or current as in latest release done, RC versions included. If not, I think we should add a tag for latest unstable release. If yes, we should add a tag for stable releases.

Initially, my strongest feeling was that latest was not updated, but that seems to have been a mistake so I think it's fine, as long as we remember it in the future :)

[lidel]

It was pointed out on IRC that latest and release tags are outdated again:

[victorb]

Seems we should update https://github.com/ipfs/go-ipfs/blob/master/docs/releases.md to include pushing the docker tags as well, as I don't think they get automatically created?

[olizilla]

We had automated docker builds working for a good while, but since the data leak from docker hub back in April, the github api token has been invalidated, so all builds are failing

https://cloud.docker.com/u/ipfs/repository/docker/ipfs/go-ipfs/builds/edit

@ipfs/infra pls can you re-connect github to docker-hub for go-ipfs autobuild magic?

[hsanjuan]

@olizilla I have fixed the "magic". Dockerhub is a broken slow mess though, so it may take some retries until builds run and succeed.

[lidel]

@hsanjuan do you know why https://hub.docker.com/r/ipfs/go-ipfs/tags/ is missing v0.4.21 tag? It looks like release tag got updated, but the one with explicit version was not created.

[olizilla]

The dockerhub is wonky. We have an autobuild set up to build the image and relase when a new version tag is added, but it hasn't triggerd for v0.4.21, and there doesn't appear to be a way to trigger it manually... we may need to manually push the image for v0.4.21

[lidel]

@olizilla good news is that release got created, so as long you got the right permissions you can tag it as v0.4.21 without re-building

[hsanjuan]

I have taken :release and tagged as :v0.4.21. I have no idea why this tag did not trigger (and the others did, maybe the build failed for some reason).

[sixcorners]

It seems that latest and release didn't get updated to 0.4.23.

[Stebalien]

Gah, thanks for the reminder. I've pushed to the release branch and the build should trigger shortly.

[Suika]

About that thing with :release and the :latest docker tags. :release is lagging 10 month behind, and :latest is currently screwing me over with a #7707 pre-release.
Would love to use :release, it it weren't dead meat. Thanks. Unless :release is not meant to follow the latest stable relase, which would be strange.

[olizilla]

Thanks for raising this! There needs to be more guard conditions in

https://github.com/ipfs/go-ipfs/blob/2ed9254426e900cf00a9b35304dc5b5de8173208/bin/push-docker-tags.sh#L62-L72

to prevent release candidates from being tagged as latest. I think we need a PR that:

• adds a guard to prevent latest from including RCs (and any other prerelease semver suffixes)
• adds a guard to prevent latest from jumping back to older semver tags if we happen to push out a bug fix for an older line

I was hoping to drop the release tag as it would be a duplicate of the latest tag, but we could add it in as an alias. I think the main problem here is that latest is including RCs and it should not.