Skip to content

Conversation

@oregonpillow
Copy link
Contributor

This PR relates to #1526 where the mkdocs site may return an http 200 code but there is an error with the mkdocs site itself.

This post deployment end-to-end test adds a very simple scraper that checks the docs site is up and that the mkdocs error '404 - not found' is not present on the rendered page.

Tested as GH action here: https://github.com/oregonpillow/mergerfs/actions/runs/17895050741/job/50880562985

@trapexit
Copy link
Owner

Forgive me but I don't see how this is useful given docs are currently built and push manually due to not finding a good way to mange it automatically.

@trapexit
Copy link
Owner

Prior to introducing mike to get versions I just force updated mkdocs each time which worked well. I suspect that is be best policy here too but with something to try to build out all tagged versions + preview/master. Let me see what I can put together.

@oregonpillow
Copy link
Contributor Author

oregonpillow commented Sep 21, 2025

Forgive me but I don't see how this is useful given docs are currently built and push manually due to not finding a good way to mange it automatically.

I thought the docs were built and deployed automatically, but i'm only hearing about mike for the first time.
I personally would have thought building +deploying the docs in automatically was the better long term strategy. In which case having a post-deploy test like i suggested would make sense. But if you're pushing manually then sure, it's not adding much value.

Why were you not able to automate building and deploying with mike?

@trapexit
Copy link
Owner

mike's UX is a bit awkward. Rather than a build stage and then pushing what you've built it's all in one. And state can get out of wack. If you delete something and don't push it at the same time there appears to be no way to force the push like with just mkdocs. And everything is stateful. Rather than having sets of docs that are versioned in some way you just build and push a version based on the existing files. So you have to basically checkout every version of your repo, deploy it, then move on. I've found it all very annoying to use but i've not seen any other way to do versioning. Perhaps mkdocs wasn't the right choice but I'm not keen on redoing it all right now.

I've got something that might work. I need to test it out. It just nukes everything and starts from scratch, iterating all tags and deploying for that version. Not pretty but should work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants