nicer URLs for ARTIQ manuals #12
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Right now the page https://m-labs.hk/artiq/resources.html points to the Hydra links that then redirect to the latest builds for ARTIQ-5.
Those URLs are a bit too long and also, after Hydra has made the redirection, the resulting URL points to a particular version of the manual which isn't updated and can even be garbage-collected, breaking user bookmarks.
I suggest instead having those URLs:
which then can access any file within the corresponding HTML manual builds.
One way we could do this is by adding a
<RunCommand>
section in the Hydra configuration which symlinks the/nix/store
output of the latest manual builds to something like/var/www/m-labs.hk/artiq/manual-beta
(or another location wherehydra-queue-runner
can write, with corresponding nginx settings to fix the URL).jq
can be a useful program to parse the JSON emitted by Hydra. IIRC the environment used by<RunCommand>
is defined by thehydraPath
attribute in/pkgs/development/tools/misc/hydra/default.nix
.Commit
25de5790cd
was a bit too eager, still playing with<RunCommand>
locally.I've fixed the issue with jq being not found, and also made it print the path to the docs.
Please review
71d631d
. I have tested the changes in a virtual NixOS machine with Hydra and Nginx.Any desires regarding code structure? As
hydraWwwOutputs
affects a few already existing configurations, splitting it up into multiple files may not be good for readability. YMMV.Looks good, thanks!
Might need "Correct Caching when Serving Static Files from /nix/store"
from https://nixos.wiki/wiki/Nginx
As my solution to that Etags problems required much more code, I have refactored out into a separate module that is configured through
services.hydraWwwOutputs
. I hope that NixOS imports merging will always do the right thing.Uh, that's quite complicated. Can't we just disable etags completely when serving those paths?
Alternatively, set the date of the manual files in /nix/store to the date of the commit when building the manual. I'm not sure if Nix enforces timestamps in the store, or if this enforcement can be disabled in a simple way.
Changing the dates in /nix/store doesn't seem easy, so the alternative option (to disabling etags) would be to copy the files and fix their dates (e.g. just set the current time from RunCommand) instead of symlinking.
I've disabled caching for now. After looking more closely at what browsers do, the "last-modified header" system would have been a problem as well.
If copying is an option, I agree: this is the simplest solution.
I will take care of other issues until you choose to reopen this one. Readers of the manual will appreciate cachability for sure.