Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publishing of docker images #3999

Closed
victorb opened this issue Jun 21, 2017 · 26 comments · Fixed by #8055
Closed

Publishing of docker images #3999

victorb opened this issue Jun 21, 2017 · 26 comments · Fixed by #8055
Assignees

Comments

@victorb
Copy link
Member

victorb commented Jun 21, 2017

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
Copy link

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

@Kubuxu
Copy link
Member

Kubuxu commented Jun 21, 2017

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
Copy link

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

@ghost
Copy link

ghost commented Jun 27, 2017

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

@skorokithakis
Copy link

Great, thank you!

@ghost
Copy link

ghost commented Jun 27, 2017

@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
Copy link

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
Copy link

ghost commented Jun 27, 2017

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

@skorokithakis
Copy link

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
Copy link

ghost commented Jun 27, 2017

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
Copy link

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
Copy link

ghost commented Jun 27, 2017

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
Copy link

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
Copy link
Member Author

victorb commented Jun 28, 2017

@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
Copy link
Member

lidel commented May 29, 2018

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

screenshot_5

@victorb
Copy link
Member Author

victorb commented May 29, 2018

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
Copy link
Member

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

Screenshot 2019-05-16 at 10 52 58

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
Copy link
Contributor

@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
Copy link
Member

lidel commented May 31, 2019

@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
Copy link
Member

olizilla commented Jun 4, 2019

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
Copy link
Member

lidel commented Jun 4, 2019

@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
Copy link
Contributor

hsanjuan commented Jun 5, 2019

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
Copy link

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

@Stebalien
Copy link
Member

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

@Suika
Copy link

Suika commented Dec 10, 2020

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
Copy link
Member

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.

olizilla added a commit that referenced this issue Apr 6, 2021
- add guard for rc releases; publish them to docker hub with the matching git tag
- make the semver regex stricter and only publish as latest when a full semver tag with no pre-release suffix is the name of the git tag.
- add `release` tag as an alias of `latest` as per #3999 (comment)

Tested manually as the push-docker-tag.sh script is set up for it:
```shell
./push-docker-tags.sh $(date -u +%F) testingsha release v0.9.0-test dry
Nothing to do. No docker tag defined for branch: release, tag: v0.9.0-test

./push-docker-tags.sh $(date -u +%F) testingsha release v0.9.0-rc1 dry
DRY RUN! I would have tagged and pushed the following...
docker tag ipfs/go-ipfs:wip ipfs/go-ipfs:v0.9.0-rc1
docker push ipfs/go-ipfs:v0.9.0-rc1

./push-docker-tags.sh $(date -u +%F) testingsha release v0.9.0 dry
DRY RUN! I would have tagged and pushed the following...
docker tag ipfs/go-ipfs:wip ipfs/go-ipfs:v0.9.0
docker push ipfs/go-ipfs:v0.9.0
DRY RUN! I would have tagged and pushed the following...
docker tag ipfs/go-ipfs:wip ipfs/go-ipfs:latest
docker push ipfs/go-ipfs:latest
DRY RUN! I would have tagged and pushed the following...
docker tag ipfs/go-ipfs:wip ipfs/go-ipfs:release
docker push ipfs/go-ipfs:release
```

fixes #3999

License: MIT
Signed-off-by: Oli Evans <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants