Config as code options for Discourse?

So not talking about the instance deployment with db etc.

Is there a pattern out there for maintaining an instance using some declarative format? Categories, tags, policies, etc. Was thinking it would be nice for our technical users to recommend changes via PR vs topic threads and manual fulfillment, but didn’t see a plugin or other “as code” tool out there focused on the organizational config of Discourse.

4 Likes

I think the expectation is that sites will use the pre-seeded site feedback category for this. Its description is: “Discussion about this site, its organization, how it works, and how we can improve it.”

That’s an interesting idea. What benefit would it have over just having users suggest changes in regular topics? Is the goal to have a way of keeping track of changes that have been made to the site’s configuration over time?

Site settings, categories, tags, policies etc, can be configured with the Discourse API. It might be possible to have a script that managed your site’s configuration via the API in a git repo. The script could be run when a PR on the repo is accepted. From my point of view this would be more difficult than manually making changes to the site’s config via the UI though.

2 Likes

10-4 on the Category. For now I was crowdsourcing a bit on an existing pattern. For me its getting that gitops style community engagement so landed with this one, but can punt it over to the other if it helps.

And yeah we use a bit of config as code for a lot of things so you get the clean revision control, deterministic roll back, clear change review, etc. GUI based changes are not bad (and what we do today via community feedback loops) but its a manual operation and the decision context can be lost to time. And the org constructs exist in the middle between the infra and the actual dialog so its not a deployment or rehydration thing.

And yeah PR based triggers (or even an Issue) can fire off a runbook that figures out the proposed change and does the operation. Doing the diff analysis and linting can be difficult which is why i was poking around to see if anyone had tried it yet. The ask is definitely square in the nice to have camp and only might resonate with a certain demographic.

2 Likes

I (and I’m quite certain our programming language community) would absolutely love this ability. In particular, I would love to be able to manage themes, components, and site texts on a GitHub repository where folks can easily submit pull requests. General site settings would also be nice, but it’s those three things that are most painful to maintain in a web UI.

If this isn’t possible today — and I don’t think it is, at least not for a paid/hosted instance — could this be re-categorized into a feature request? In particular, it’d be amazing if themes and components could just point at a git repo.

Or, alternatively, has anyone built out the GitHub trigger integrations proposed above?

1 Like

Immediately after writing that, I thought to double check the UI. It seems this is possible — at least to create/import a theme from a git repo! How does this work for updates? Is it able to pull new commits? I found Installing a theme from a private Git repository, but that doesn’t discuss update.

Is it possible to convert an existing theme or component to track a git repository?

You can export a theme, upload it to a repository, and install that.

All remote themes have a section at the top where you can decide if you want it to update automatically when Discourse is updated. Furthermore, there is a background job that checks if a more recent version is available, and you can check for new updates manually too. When a new version is available, the button offers to update the component.

You can also find that information in the guide about Installing a theme or theme component.

In case you haven’t already found it, there is also a tutorial about theme development

3 Likes

That’s great, thanks @Moin! That covers two big sources of our site’s customization.

I’d still really like to use git to manage the Site Texts as many of those (like the guidelines and FAQ and such) are long, non-trivial, and can be open source for community input and review.

The other site settings would be nice to have, but definitely not as crucial.

Those are usually base on a topic in the staff category. I think you can move them to a different category and make the post a wiki. Then your members can edit them.

You can also use the FAQ URL, Privacy policy URL and ToS URL site settings and host these somewhere else

1 Like

Yeah, but the FAQ URL setting unfortunately has other behaviors that makes its use very much self-defeating for this purpose.

Just to point out that it is clear that it is already possible to manage content in source control, take a look at this topic, it’s maintained on GitHub:

at the bottom:

though I’m not sure if this functionality has yet been released or announced (or if that’s intended)

1 Like

I’ve started fiddling around a GitHub action that submits updates to the site_texts section of the admin panel via API. It’s pretty rudimentary at the moment (and is failing for big values with a 422 for some reason), but it’s promising.

Definitely needs more work.

1 Like

We don’t currently have any plans to release it as a re-usable tool. But you can check the code for our sync here. It leans on all the normal Discourse REST APIs, including a data-explorer query (details here).

2 Likes