Looks like we found why whatever we tried resulted in our files being overwritten in the app during the rebuild process:
This is the reason seems to be because launcher pulls the base discourse image and that image has a.git directory and the git config file naturally points to the master discourse repo and then it overwrites our changes:
# Add a single retry to work around dockerhub TLS errors
$docker_path pull $image || $docker_path pull $image
Before we mistakenly thought launcher built the image (how did we miss that?!) and it’s clear now that it pulls a base image from docker hub.
Back to the drawing board!
Is there a flag we can set which keeps launcher from pulling the base image and instead builds it?
Totally agree with you that plugins and theme components are the way to go! That method is fully supported and is good to stay in sync with the meta development team.
It’s also good to be curious, to explore possibilities, and to gain a deeper level of Discourse understanding; and after reading this topic by yesterday, I created a local Docker registry, tagged the Discourse base image locally, pushed that image to my new Docker registry (localhost) and then rebuilt a Discourse app pulling the base Discourse image registry.
It is fun, I think, to experiment and learn more about Discourse and I learned a lot from this sys admin exploration / experiment. Of course, this is not how we would run a production application, but I did learn a lot from going though the steps it takes to pull the Discourse base image from localhost versus remotely, and it was surprisingly easy to do, so I wrote this experiment up to share with other curious sys admins:
I hope other sys admin explorers will benefit from this experiment in some small way.