add mkdocs post-deployment test#1529
Conversation
|
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. |
|
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. |
I thought the docs were built and deployed automatically, but i'm only hearing about mike for the first time. Why were you not able to automate building and deploying with mike? |
|
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. |
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