Could we just change the distro.properties file to use something like this:
spa.spaPath=$SPA_PATH
spa.apiUrl=$API_URL
And then go back to leveraging envsubst
? I don’t think they need to be actual values…
Could we just change the distro.properties file to use something like this:
spa.spaPath=$SPA_PATH
spa.apiUrl=$API_URL
And then go back to leveraging envsubst
? I don’t think they need to be actual values…
Well when I tried, the build failed. I think there is a subsitution happeing beforehand and it tells me the value is empty. Tried to escape it with \$API_URL
but it also fail (I don’t recall the error).
And then I stopped trying.
So testing things out, it seems to work for me if it’s $SPA_PATH
but ${SPA_PATH}
causes an issue. I think that’s because the resources plugin uses ${...}
to denote variables it should substitute.
I’ve pushed a update for the embedded Dockerfiles and a docker-compose-embedded.yml file that orchestrates them together.
I think we’re ready to start setting up a Bamboo job to build this branch and push the Docker images out there. Any objections?
Alright after a few more commits and messing around with things, we have a working CI pipeline to build 3.x and actual images for the gateway, the frontend, and the backend with all the necessary components embedded in them.
That build has two pathways, one to build a “dev” image with the latest ESMs (at the time it’s run) and one to build a “demo” image with the latest released versions of the ESMs (at the time it’s run).
Next, I think we need to get the necessary docker-compose stuff added to the ansible configurations and then get it deployed somewhere.
We’d really like to release 3.0.0 to the public within the next week if at all possible, and it would be ideal to do it on demo3.openmrs.org
Created this ticket for @ibacher to help us track this work: [MF-805] Set up demo3.openmrs.org (Demo/Production Environment) - OpenMRS Issues
(Sorry Ian, I know you have heaps on your plate, so this isn’t a complaint, just an effort to keep up our momentum)
demo3.openmrs.org
is not a great subdomain, looks like there is a demo1
and demo2
and that demo3
is just there for redundancy.
That is great → o3.openmrs.org
(Amusingly O₃ happens to be the chemical element for trioxygen.)
I actually really like o3.openmrs.org
, so I vote we use that for the demo site. We’re also going to have a separate dev site. Do you have any naming suggestions (right now, it’s dev3.openmrs.org)?
I’m alright with o3.openmrs.org. However, the original reason for demo3 was because of the current name, “demo.openmrs.org” for the 2.12 RefApp.
I think we need to plan ahead now, for the future where we’ll have removed the “3”.
So re. Dev Site - I am fine with dev3 for now; however, I think now is the right time to just leapfrog straight to “dev.openmrs.org”. (I see that this currently goes to the Add Ons site; not sure if anyone’s using that pathway though - I’ll see if I can find any data in our Analytics…)
@mksd @ibacher @dkayiwa are you okay with this approach? I realize some folks may be used to finding the 2.x experience at demo. and dev., but if we’re serious about our 3.x direction, then it’s probably good to explicitly head in that direction earlier. We can also make use of the Website and a Blog post to help make the community aware of the change. I can also kick off a dedicated Talk post before we switch over, and we can confirm with the TAC team on Monday too.
If it’s more expedient (due to the current 2.x living on demo.openmrs.org and dev.openmrs.org already going to Add Ons) I’m also fine with moving ahead with o3. and dev3.
Update: Discussed with Ian, and we decided that at this moment, it makes the most sense to proceed with:
Then pretty soon, we’ll switch over to demo. and dev., and auto-direct o3 and dev3 there.
So no immediate dramatic changes for the community at the moment.
Is that o3, O3, or 03?
o as in “Oh Burke” haha. Great point though Burke. All the more reason to transition over to just demo.openmrs.org soon. (I’m imagining the current 2.x demo would go to legacy.openmrs.org)
Next steps conversation trying to happen on this slack channel: #o3-pipeline Slack
Please also see Brandon’s RFC for Versioning: RFC: Version Tracking for Releases by brandones · Pull Request #31 · openmrs/openmrs-rfc-frontend · GitHub
Note that both of the following are now live and have sample/demo content:
Credit and much, much appreciation to @ibacher for setting both of those up and the CI pipeline that supports them!