If you want my early feedback, you could add me as a reviewer, so I could actually add comments before you merge.
You want to move init.sh to a different folder, like root ‘/’ instead of serving it as part of nginx.
You really do not want to copy .env to your docker image. You should be looking for environment variables. I will change the deployment to actually provide them. If in DEV you want to use, it’s up to you, but it’s not something we’ll be doing in prd because it won’t work.
Add ‘nginx -g "daemon off’ at the end of your init script, it’s much simpler to follow
Thanks @darius. I’ll be using a workaround in the meantime by Retiring the concept, deleting it’s reference from a Dictionary and adding the new version of the Concept to that Dictionary.
I’m working on a feature to be able to list concepts/mappings in a collection, which can be updated to newer versions and in a subsequent request have them updated.
You are discussing something a bit different, i.e. being able to edit a concept/mapping and at the same time have it updated in a particular collection. You need to handle that from the UI for now.
Just ignore the .env file. You should use plain environment variables.
You don’t want to use init.sh anywhere outside docker. I’d recommend you just set reasonable defaults, and you should be able to override it for development somehow (environment variables or whatever)
You want to hardcode the name of the environment variables; you do now want to print all of them.
Can I also check that we are making progress on being about to test a build against the full CIEL dictionary? Do we have a staging server to do this in the works?
That doesn’t sound quite right. Why do you have to retire the concept?
When you edit a concept with the API it should automatically create a new concept version, and somehow mark the older one is not being the latest. You do not have to do any further operations on the concept. You do need to do further operations on the collection, i.e. remove the old version and add the new version.
Cool to hear. We’ll want to take advantage of this post-MVP. Is this interactive, i.e. can you choose which ones to update and which ones not to?
@akanter, this is in progress. Specifically the conversation that’s going on between @cintiadr and @judeatu is about doing the back-end plumbing so that the application can be run in multiple environments. (I guess that now it’s hardcoded to the QA environment we’re using.)
I need some help, about the implementation you want. I have talked to some DevOps engineers at the office and they don’t seem to understand why we are using the init.sh because of the following reasons
Currently, when I use the QA docker-compose file in my local docker-compose file and pass environment variables in the environment I am working in, the docker-compose file will pick them up as required.
Basing on this the variables can be got from the deployment environment shell and passed to the app as shown here
These variables can then be accessed in src/config/index.js using process.env.
The above procedure then eliminates the need for the shell script because the environment variables can be accessed directly and there defaults values that can be used if they are not provided.
The init.sh file only creates a JS file with the environment variables from the .env file put in a Javascript object.
This would still be of no use if I don’t have a .env file to pick the environment variables from.
With that said, I am having a hard time trying to implement what you requested so I request for sync with you on HangOut if your available so that you can help me implement this the best way you would want it.
Here is the PR where I tried to implement what you had requested in the first format
The biggest problem am having is passing environment variables using a .sh file without using the .env file. Because the init.sh file I currently have is picking the environment variables that I store in the .env file then create a JS file called env-config.js with the variables in an object as shown below;
Also when I use the QA docker-compose file in the local test docker-compose file as shown here all I have to do is pass environment variables in the environment using a .env file or an export command and the docker images can access the variables from shell/environment as its stated in the docker documentation
I’ve mentioned in this topic a few times, but I’m a volunteer. I do have a full time job (that is not OpenMRS related at all), plus family commitments and I’m in the wrong timezone, I cannot just drop everything to join unscheduled calls for OpenMRS. Please do not expect any answer from me in less than 24h, I do help OpenMRS on my free time.
I don’t think this is how it works.
You don’t have a node backend, your server is nginx serving static files. Id doesn’t read any environment variables, as it’s serving only static files. It’s not reading anything from the server.
Instead of using a .env file created during build time, I asked that it read the environment variables. That was all.
Please ignore the .env file, I’m using it, but it’s just confusing you. Just pretend it doesn’t exist, because it should be transparent for your docker container. The environment variables will magically appear there.
I reviewed your PR, and I don’t think that works. You actually undid what I thought it was a solution which was almost done (generating the js file from init.sh during start up), so I’m not sure what to say.
Hi @raff,
I believe you should implement it as you said because me trying to implement it may take more time which is slowing down the product release.
I appreciate the help provided on trying to implement the task, but me being a beginner in the DevOps work(Docker, Bash). I am having a hard time trying to implement it as required and it may take longer than expected.
Okay I see. But please do ensure that you also get things working right for concept edits.
Alternately, if concept edits are already working right then perhaps this code is already implemented and you can leverage it. Or else my understanding of the situation is wrong…
The edit is not working right for concepts, therefore, I’ve created a ticket to fix it. I’ve also added a “before” video to the ticket to illustrate the current issue if you’d like to have a further look at it.