FYI for contributors: docs PRs will no longer be automagically shipped to the docs site until a release is made

[jamietanna]

As part of a change we've made this week to fix a couple of issues with the docs site (such as #38796), we've now got the docs site (https://docs.renovatebot.com/, source) updating itself when a new tag is released of Renovate.

Previously, we updated the Git submodule pinning to the latest commit on HEAD (at a given time) and would use that, which would mean that periodically, a docs PR that was merged would then land on the docs site maybe by the time a new release was made, maybe not.

Now, this means that docs PRs won't land on the docs site until there is a new release of Renovate (plus a little delay, waiting for Renovate to perform branch-based automerge on the docs site)

I wanted to share this with y'all, and see if we wanted to make any tweaks to the workflow, to make sure that this was something contributors were aware of having changed.

A couple of thoughts:

• Make it so docs PRs trigger a new code release
• Keep the Git submodule in the docs site pulling latest HEAD, while we keep track of what the latest Renovate tagged release is via a version pin
• Do nothing, and see how this goes for a bit

Related: renovatebot/renovatebot.github.io#108

[viceice]

I'm in for not release for docs prs and use the docs asset from release to publish docs. They should be fully prebuild, so the publish job could be much simpler

[viceice]

what about to entirely moving the docs publishing to the main repo? With the cname thing we can also use the main repo 🤔

[jamietanna]

I think moving everything into this repo is fine - I don't know if @HonkingGoose (emeritus contributor, I know!) would know if there's a good reason to keep them separate, given we're now mostly doing all the builds in this repo + this repo owns a lot of the files that are used by MkDocs to build