TOC expand-collapse icons - take 2.1

[bmunkholm]

Summary of the changes / Why this is an improvement

#664 didn't work for multiple projects.
This is a restore of the branch for now.

[amotl]

The review on GitHub shows like this PR might include effectively the same like the previous GH-664? I can't spot any reverts.

[bmunkholm]

Yes it's the same. I have reverted the previous merge directly on main until I figure out what's wrong. That's why this is in draft again.

To recap: With the release 0.43.0 that included GH-664, I noticed the TOC became "weird" (missing some entries when clicking various projects). It may have been a premature conclusion that something was wrong, and it could possibly be because caches hadn't been fully cleared. It requires a bit more testing - preferably locally if possible. I just don't know how to do that.

[amotl]

Yes it's the same. I have reverted the previous merge directly on main until I figure out what's wrong. That's why this is in draft again.

I see, thanks.

I noticed the TOC became "weird" (missing some entries when clicking various projects). It may have been a premature conclusion that something was wrong, and it could possibly be because caches hadn't been fully cleared.

Yes, this can be weird when bringing in significant changes in those areas where intertwingulation is negatively high. Otherwise it's mostly a non-issue because changes are incremental and mostly smaller, i.e. much better manageable.

Documentation stack as sandbox

Do you know how to build the complete docs locally with a custom theme without publishing?

I don't know how this is ergonomically possible without overengineering it, specifically because "there is no local", when a software platform like RTD is involved, but many wirings are intertwingulated with the fact being published on cratedb.com.

The best low-effort way forward is to run dev releases of the crate-docs-them, and selectively enable them on one or more innocent low-impact projects like crate-dbal, crate-npgsql, or such, and see how that works when navigating between both after making sure the relevant caches have been purged.

Fastly utilities outmoded

After a CI rebuild of all docs, how can I know that all caches of any kind are cleared to ensure that the docs can be finally validated?

I think there is no way to know. Also, currently there is no way to purge whole content sections like before, see fastly issues, most probably due to INFRA-3320. This snippet at least includes information how to purge individual single HTTP resources.

The way this workflow step was more solid before dropping maintenance, was that we have been able to purge the cache slots on demand. The Jenkins job fastly_purge just worked well, which is using Fastly's surrogate key mechanics to purge individual complete documentation sections, or, when required, everything.

[amotl]

Also, currently there is no way to purge whole content sections like before [...]

Maybe it is possible from the Fastly Web Console? I never used it, but @WalBeh and @msbt did avidly.

[bmunkholm]

Closing this in preference of #681 which basically just cherrypicked the original commit together with a fix for the build warnings fix that caused the problem.