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

[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

[HonkingGoose]

I want the docs in the main repository too. 😉

I don't know any good reasons to keep the docs separate. Maybe @rarkins knows why the docs repository was kept separate from the main repository?

[rarkins]

I don't fully remember the original reasons but if none are known now, it's probably a good idea. Very early on there wasn't as much control over sequencing publishing, for example. One potential downside is that:

• docs: commits don't trigger releases
• You normally don't want to deploy docs unless it's a release
• If you want to change something about how the site is deployed or looks, you'll need to create an "unnecessary" release (no change to CLI functionality) to bump it

[viceice]

we already only deploy releases to pages. @jamietanna recently changed the submodule config to follow tags instead of default branch

[jamietanna]

Looks like I forgot to follow-up here: #39878 is raised for this

I think I prefer "every commit on main pushes the docs site", but we can always see how it goes and if we need to get docs changes / docs site changes shipped more frequently, we can change it