snapcraft has a runtime dependency on snapd, and in rare cases when
there is incompatibility between the two, one may need to request both
snapcraft and snapd from specific channels to correctly complete
builds.
This was especially profound when we lost ability to rebuild core22
snap on riscv64 due to a regression in snapd, and unable to instruct
launchpad to temporarily use snapd from any other channel but stable.
This location is used to serve machine-readable API documentation used
by `lazr.restfulclient`, and if it sees a response with `Cache-Control:
public,max-age=5184000` then it won't refresh its cache until `max-age`
has passed - 60 days! This is OK for URLs whose contents change very
rarely, but for machine-readable API documentation we want changes to be
effective more or less immediately, and they aren't otherwise hit often
enough to need such aggressive caching.
(On production, https://launchpad.net/+apidoc/ and https://api.launchpad.net/ previously had different caching
configuration for the same documentation. This brings the former into
line with the latter, since they're now routed to the same backend, or
at least will be once we revert an emergency frontend patch - but I
think that's OK.)
`launchpad-assets` needs to build the files it serves (particularly API
documentation) with the correct `LPCONFIG` so that they embed the
correct host names. The previous arrangements of simply running `make
build` when creating the virtualenv couldn't possibly achieve this,
because the necessary configuration file didn't exist yet. Run `make
build` after creating the configuration file instead.
Doing this uncovered various problems with the configuration file we
write out: it didn't have enough entries to support running
`utilities/create-lp-wadl-and-apidoc.py`. Also, since the
`/srv/launchpad/code` symlink is now changed before all the assets are
built, the Apache configuration now has to refer to the
most-recently-configured payload directly using its build label rather
than using `/srv/launchpad/code` as a shortcut.
snapcraft has a runtime dependency on snapd, and in rare cases when
there is incompatibility between the two, one may need to request both
snapcraft and snapd from specific channels to correctly complete
builds.
This was especially profound when we lost ability to rebuild core22
snap on riscv64 due to a regression in snapd, and unable to instruct
launchpad to temporarily use snapd from any other channel but stable.
