-
Notifications
You must be signed in to change notification settings - Fork 13
ci: Publish haddocks to GitHub Pages #183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
In between full Hackage releases, it would be nice to be able to read haddocks for the latest commit on the default branch. This commit builds the haddocks in CI, and publishes them to GitHub Pages. In more detail, this commit breaks the `cabal haddock` step out of the testing job into a separate job for the sake of controlling concurrency and permissions, while reusing the cache from the build step to build the haddocks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This overall publishing should be fine in general. I don't know how fully useful this will be since it will only be the docs for this package and so I expect cross references won't work. Another thought is that if there are space constraints on gh-pages (although I'm not aware of any, and even with our larger projects I suspect the size of generated docs is rather minimal).
This will only provide the latest master version of the docs.
A couple of comments, one geared towards minimizing the support overhead.
Umm... there were comments, where did they go, Github?! I'll try to recreate after my meeting. |
OK, comments added. |
Ah, it appears that Github Pages needs to be enabled in the repository settings. @kquick Do you have sufficient permissions to make that happen? |
Ah, now it appears that I can't do a test deployment on this branch:
@kquick do you want to try temporarily changing the rules in the settings, or would you rather try merging this? It will probably work... |
Hmm...
FWIW, githubstatus.com is not reporting any issues. I wonder if there is a way to give a more specific name to the artifact, perhaps including the workflow/job run ID? |
Oh, this appears to be an issue specifically related to retrying CI builds with these actions:
I will try adding a new commit instead. |
It works! 🚀 http://galoisinc.github.io/parameterized-utils/ |
...as the latter is actually the resource being protected.
4178564
to
9baa199
Compare
Current status appears to be that identifiers for e.g. |
GitHub publishes some documentation on usage limits. It's not clear to me from those docs whether or how much our organization is charged for the storage, but as you say, the docs are likely reasonably small. The artifact
Indeed. |
fd2b426
to
60f0ae8
Compare
Unfortunately, |
I've got the links to other packages going to hackage.haskell.org now. |
5366bac
to
4cd39c3
Compare
FWIW, these deployment errors seen on this PR seem to have to do with competition between the |
In between full Hackage releases, it would be nice to be able to read haddocks for the latest commit on the default branch. This PR builds the haddocks in CI, and publishes them to GitHub Pages.
In more detail, this PR breaks the
cabal haddock
step out of the testing job into a separate job for the sake of controlling concurrency and permissions, while reusing the cache from the build step to build the haddocks.I'd be completetly fine with hearing that we don't think that the maintenance is worth it, I mostly wanted to prototype this for use on our repos that we don't publish to Hackage (e.g., Macaw) and just figured I'd make a PR in case others thought this would be useful.
If we did want to merge this, we would want to temporarily disable the
if
stanza that only deploys on themaster
branch, to try it out.