Comments (4)
@bparees Are there any requirements for having directory for each version?
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
- see/understand which files are for a given version
- build an image for a given version
it should be fine.
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.
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.
from container-common-scripts.
Is this slowly moving to discussing sclorg/postgresql-container#139 ? That would be something where I would vote +1.
from container-common-scripts.
+1
To note, it seems to me that change only point 2. would work too for some git commands (eg. git blame
).
- but then we needed to work on 9.4, so we rename whole 9.2 directory into 9.4 and commit this. Then copy 9.4 as 9.2 and add it. Push these two commits together.
But having latest
directory seems more clean to me. Also
@bparees Are there any requirements for having directory for each version? I know that images should be able to build with docker build
command.
In case we want to solve problem with multiple versions and would change the workflow - adding latest directory.
So why not to remove directories and have only one directory with dockerfiles: Dockerfile.9.2
, Dockerfile.9.4
, Dockerfile.9.5
. Have only one scripts and in dockerfiles set some for example VERSION
variable to allow differences in scripts.
from container-common-scripts.
+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.
So why not to remove directories and have only one directory with dockerfiles: Dockerfile.9.2, Dockerfile.9.4, Dockerfile.9.5. Have only one scripts and in dockerfiles set some for example VERSION variable to allow differences in scripts.
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.
from container-common-scripts.
Related Issues (20)
- Print info about container image tested in test.sh HOT 4
- generator.py fails the sanity check HOT 2
- Failure in case of OpenShift 4 connect
- docker --iidfile unknown flag HOT 1
- Traceback in cgroupt-limits HOT 1
- In case of '.git' directory does not exist build and tag is failing.
- regression in 'ct_clean_app_images' HOT 2
- Stop tests on SIGINT HOT 3
- Test log output improvements needed HOT 3
- Make sure that failed test in the end always fails the testsuite
- database library would be nice for mysql, mariadb and postgresql containers
- OCP tests: Make sure that failed test in the end always fails the testsuite HOT 2
- Do not try to get compressed image size when tests are interrupted HOT 4
- stop rebuild and testing of centos7 images HOT 1
- Migrate fedora images to f38 where possible HOT 5
- grep: warning: stray \ before - HOT 3
- Review hotfix for removing set -e from test-lib HOT 1
- Remove dead branches and set delete on merge as default HOT 1
- Fix check_latest_imagestreams.py HOT 1
- Adjust bot for common submodule updates.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from container-common-scripts.