Open franck-boullier opened 4 years ago
Sorry, I don't quite understand. Why does it have to be "has to be specific to each environment" exactly?
https://hub.docker.com/repository/docker/uneet/frontend will work across {dev,demo,prod}.
https://hub.docker.com/repository/docker/uneet/frontend will work across {dev,demo,prod}.
but is will not work on a different INSTALLATION of Unee-T (Unee-T INS, other future Unee-T installation) <--- that is a problem
Also with how the code is built currently, if someone forks the Unee-T frontend codebase and tries to do some changes to the code, then these changes will trigger a new build of the docker image.
One issue is that this build in the forked repo will automatically fail (as is should) because it's trying to update the Docker image to the Unee-T Dockerhub account and has no credential for this account.
Example: an update to the forked code Unee-T INS will try to build a new image in the Unee-T main code <-- this is wrong
I don't understand why uneet/frontend will not work in another different installation.
Because you intend to fork the code? Or what is the reasoning?
I don't understand why uneet/frontend will not work in another different installation.
One of the reason is explained here https://github.com/unee-t/frontend/issues/895#issuecomment-584442683
Because you intend to fork the code?
yes the code has to be built so it can be easily forked (see the Unee-T INS example as a case in point)
So when you fork the repo you will need to ensure the Docker repo variable is updated.
Don’t quite understand this “unneccessary complexity” in the bug title. It’s a reality if you fork the code.
. It’s a reality if you fork the code.
It does not have to be a reality if we create a dedicated repo for the Image we need. Read the description of the issue again if you have issues understanding the concepts I'm trying to highlight.
For the Unee-T frontend to work, we can describe the things we need as such:
In order to deploy some of the Unee-T components (frontend but also bugzilla-customization) We need to:
In the current version of the master, we have fused the creation and test of the Docker image A with the creation and test of the MEFE code C.
Context:
For the Unee-T frontend to work, we can describe the things we need as such:
In order to deploy some of the Unee-T components (frontend but also bugzilla-customization) We need to:
Other things to Keep in mind:
The problem:
In the current version of the master, we have fused the creation and test of the Docker image A with the creation and test of the MEFE code C.
Some of the consequences of the problem:
Each installation/Environment has its own custom Docker Image A:
This is not necessary: each Unee-T installation (Unee-T, Unee-T INS, etc...) should share the same docker image
frontend-docker-image
as they are sharing some of the other Unee-T libraries (ex:unee-t/env
)We do many unnecessary steps each time we change the MEFE Code C:
Today, each time we do a minor change in the MEFE code C we are:
In the vast majority of the cases, we do NOT need to do Step 1 and 2.
It should be possible to
Maintenance of the Docker image is problematic:
Because each environment (DEV, PROD, DEMO) in each installation is building its own Docker image A, it is complex to centrally:
Possible solution:
We can/should create a specific repo
frontend-docker-image
dedicated to maintaining the Docker Image A. We can then use that repofrontend-docker-image
as a single central component that can be shared by all the forks of the MEFE Code C (Unee-T, Unee-T INS, etc...).@kaihendry do you have a better solution that will solve all the issues that have been listed here?