What is the best way of deploying documentation for tags that were (for some reason) skipped?
I tagged some versions of a package when, probably, something either in Travis or in the docs folder was misconfigured. As a result, the associated folders are missing from the gh-pages branch.
How does one fix this? Is manually building and pushing the missing folders the only option?
If the Travis failure was just temporary you should be able to restart the Travis run for the tag and it should deploy.
If the documentation does not build on that tag however, then you have to build it manually and push it to gh-pages. If you use the same naming convention as Documenters deployed docs it should be picked up in the version selector during the next real Documenter run. It can sometimes be difficult to build the correct docs locally, e.g. links to the repository etc may not work.
I would argue that the documentation for old releases are not that important anyway, and you might just as well fix your issues and make a new release that has working docs to avoid this hassle.
Edit: It is a good idea to check that the documentation builds correctly on master, just as you are checking that the tests pass, before tagging a new release.
Would this be a good idea to implement as a Github web hook or similar? Pull request would have a bot commenting that documentation builds without errors.
If you build the docs the way Documenter’s manual recommend it will fail the build if the doc build fail.
Yes, I completely agree, but
was it always the case? I’ve updated my Documenter setup and now Travis shows an appropriate build step for documentation, but some time ago I had it set up differently, and documentation failures wouldn’t fail the whole build.
Thanks for all the suggestions, I’ll maybe just wait for the next tag and that’s it.