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

Docker Image Tagging Confusion #85

Open
pahansen95 opened this issue Apr 15, 2021 · 7 comments
Open

Docker Image Tagging Confusion #85

pahansen95 opened this issue Apr 15, 2021 · 7 comments

Comments

@pahansen95
Copy link

I was having issues running Adam in Docker on a t4g instance in AWS. After running around in circles trying to figure out what I was doing wrong I realized after looking at the Docker tags that latest was released 5 months ago.

Looking at your GitHub Workflows I see you don't tag any image as latest. Would it make sense to add the tag under the publish workflow?

Alternatively, you could call out in the README one should explicitly define a tag. Currently all of the examples just use lfedge/adam.

I'd be happy to make a pull request either way.

@rvs
Copy link
Contributor

rvs commented Apr 15, 2021

This is excellent point @pahansen95 ! @deitch @giggsoff -- any thoughts on this?

@giggsoff
Copy link
Collaborator

I think it is good idea to add latest tag to the publish workflow. Feel free to open PR for this.

@deitch
Copy link
Contributor

deitch commented Apr 15, 2021

I do have an opinion on it, but I am not 100% sure it is correct, so open to discussion.

I never have loved the mutable latest tag; it causes more pain than it is worth. That having been said, lots of people use it, so we might have to live with it.

However, living with it means we should decide where it goes. In my opinion, latest (if it must exist) should go only on the latests released version, i.e. one with an actual version tag, and not on the head of master branch. In other words, it should be part of the release workflow, rather than the publish workflow.

If we need a mutable tag pointing to the latest head, we can add one for that as well.

All of that having been said, this is important:

you could call out in the README one should explicitly define a tag. Currently all of the examples just use lfedge/adam.

We could, and probably should. Is it wrong, though, for us to call out to use the latest released version? Or perhaps we need to be releasing more often. :-)

@pahansen95
Copy link
Author

If nothing else the latest tag in Docker Hub should probably be removed for now. I think it's safe to assume people trying out the project are following the README & will pull the latest tag if using Docker.

@deitch
Copy link
Contributor

deitch commented Apr 18, 2021

I think @pahansen95 raises an important issue: the docs are confusing, because we don't have anything sane that latest points to. We don't want latest to point at HEAD of master branch, because that would change too rapidly and be confusing. But we do want something reasonable so users aren't confused.

As an aside, thank you for sharing it @pahansen95, so that we can avoid others also running around in circles.

I propose the following:

  • latest should point, always, at the most recent semver release
  • master should point to HEAD of mainline branch
  • (probably most important of all) we should cut release and keep doing so

To a large degree, this is an outcome of our not cutting releases.

I would like to hear feedback from the 3 others on this issue before implementing.

@rvs
Copy link
Contributor

rvs commented Apr 19, 2021

FWIW @deitch -- EVE itself follows a slightly tweaked version of the above:

  • latest should point, always, at the most recent semver release
  • snapshot should point to HEAD of mainline branch

I'd suggest whatever we do we need to make it the same between EVE and Adam. Otherwise confusion will abound.

@deitch
Copy link
Contributor

deitch commented Apr 19, 2021

That makes sense. We will follow that with adam.

We really should document this somewhere so that future projects (maybe eden too?) can have a written standard to follow.

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

No branches or pull requests

4 participants