-
Notifications
You must be signed in to change notification settings - Fork 45
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
latest
directory in container git repositories?
#4
Comments
master
directory in container git repositories?latest
directory in container git repositories?
Move '9.2' into 'latest' to keep the whole commit history.
Copy 'latest' into '9.2'. We sacrifice git history of 9.2 to have better history in latest.
Copy related changes from 9.5 into latest, and replace the whole 9.5 with symlink to latest.
+1 To note, it seems to me that change only point 2. would work too for some git commands (eg.
But having In case we want to solve problem with multiple versions and would change the workflow - adding latest directory. |
+1 from me, having latest with the full git history would be really useful. I often find myself trying to find out what got changed where.
This would work in case there are no major differences outside of Dockerfiles between the images (which I think is the case for most of the images right now). But not sure if that can be guaranteed (=we want to work around) in future. |
there are no requirements, since you guys own the CI/CD infrastructure and getting the images built on OSBS, you're welcome to structure the directories in whatever way you see fit. As long as users can easily clone the repo and
it should be fine.
i think you're likely signing yourself up for a bit of pain here. How many versions of a given image does the SCL team imagine will be supported at a time? The small pain of maintaining 2-3 dockerfiles may be less than the pain of maintaining some scripting/tooling that produces those 2-3 dockerfiles w/ specialization. We've historically had cases where package names change or get added/removed, so you're going to have to deal w/ that if you are trying to generate multiple dockerfiles from a common definition. |
Is this slowly moving to discussing sclorg/postgresql-container#139 ? That would be something where I would vote +1. |
Move '9.2' into 'latest' to keep the whole commit history.
Copy 'latest' into '9.2'. We sacrifice git history of 9.2 to have better history in latest.
Copy related changes from 9.5 into latest, and replace the whole 9.5 with symlink to latest.
Copy related changes from 9.5 into latest, and replace the whole 9.5 with symlink to latest.
Copy related changes from 9.5 into latest, and replace the whole 9.5 with symlink to latest.
Move '9.2' into 'latest' to keep the whole commit history.
Copy 'latest' into '9.2'. We sacrifice git history of 9.2 to have better history in latest.
Copy related changes from 9.5 into latest, and replace the whole 9.5 with symlink to latest.
Move '9.2' into 'latest' to keep the whole commit history.
Copy 'latest' into '9.2'. We sacrifice git history of 9.2 to have better history in latest.
Copy related changes from 9.5 into latest, and replace the whole 9.5 with symlink to latest.
Closing this issue. We do not have capacity for implementing. |
It is really ugly that we loose the git history all the time with new versions of our containers, speaking in examples - consider PostgreSQL container:
9.2
directory, we iterated a lot (git blame and git history gives us useful info9.4
, so we copied and pasted whole9.2
directory into9.4
, which means that the whole9.4
directory lost all the useful commit history9.5
made this even worse, and upcoming9.6
won't help obviouslyWell, e.g. in Fedora dist-git, we have
master
branch which guarantees that all the necessary info forgit blame
persists. It is fair also to keep the "authorship" of contributions.Perhaps we should have e.g.
latest
directory now (instead of9.6
) and make the9.6
be a symbolic link tolatest
?The text was updated successfully, but these errors were encountered: