Theme automation

Hi all, Im new here :slight_smile:
So Im running a Dockerized version of bitnami Discourse ( the latest one ) on a Kubernetes cluster, really seems to be a great project. However Im facing a kind of problem trying to autmate a theme installation. Essentially I need to build, deploy, run and configure this docker image from a CICD, so at the very first login everything is ready. About the configuration stuffs there is the customized theme installation. As far as a could understand from several forums and docs there is no a native way to install it programmatically, i found just a click by click guide ( correct me if Im wrong pls ).

My first idea was to add the theme files “manually” in the Discourse file systems via k8s, but as I can see Discourse manage its files in a strange way, renaming them according to its own internal logic and making it impossibile to predict.

Looking in more detail i found this great cli called discourse_theme , the problem here is that I would still need to generate an api key from discourse first, otherwise it cannot work ( again… correct me if Im wrong ).
So in the end Ive a couple questions:
first, is there a different/native way to install programmatically a theme in Discourse that I missed?
and on the other hand, is there a way to get an api key from discourse from a script?
and at the end, does anyone know some kubernetees trick to workaround this kind of issue?

Many thanks in advance

best regards

That’s supported when using our official install method: Install a Theme programatically

1 Like

I think that the only solution is to build an image that includes the plugins that you want, push it to a docker repo, launch it with the appropriate ENV variables, and at some point see that the database is migrated and assets precompiled and pushed to S3 on (at least) the first time the image is run. You might want to migrate once with SKIP_POST_DEPLOYMENT_MIGRATIONS set while the old image is running and then again after the new image has launched and the old ones have shut down with SKIP_POST_DEPLOYMENT_MIGRATIONS turned off or run the db:ensure_post_migrations rake task.

You can run a rake task in one of your running images, something like

         rake api_key:create_master['description of key']

The above might be enough to get you a bit further. I’ve run kubernetes instances for clients on GCP and AWS in the past. I was never 100% happy with how it worked (it worked perfectly from the client’s perspective, it just wasn’t very elegant from mine, but it wasn’t so inelegant that I bothered to fix it, either!). I don’t have much more to offer here, but feel free to contact me directly if you need more help.

1 Like