Add project, distribution and source_package_name columns to webhooks to allow new webhook targets (specifically for bugs)
Updated the 'one_target' constraint: A webhook can only have one target, but when the target is a source_package, then the distribution column should also have a value
Include download-cache/yarn/ in deployment tarballs
This adds about 25 MiB to the size of those tarballs, but it makes it
possible for us to run `make build` in a charmed deployment, which is
needed for deploying our frontend assets using Juju.
Make apidoc generation work outside a git working tree
Our machine-readable API documentation files are generated using the
time of the last commit as their file modification times, in order that
`ETag` headers are consistent. However, when building API documentation
in a charmed deployment, we don't have a git working tree. Pick up the
timestamp from `version-info.py` instead.
Revert "Include built assets in deployment tarballs"
This reverts commits 58bc1d894a8d5f7e17b643d11d8c54185eb010f8 and
97990c559e9c4a7234c78b2aa238523c432a2abf. It turns out that it's
impossible to include assets in deployment tarballs, because API
documentation includes the API host name and so needs to be built
separately for each environment. We'll need to take a different
approach here.
The `build_wheels_only` target in the `Makefile` is used by both legacy
deployments (via a complex chain of systems that include a call to `make
build_wheels`) and Juju deployments (via a Jenkins job that calls `make
publish-tarball`). We need `make publish-tarball` to build assets in
order to support a future charm, but `make build_wheels` can't do so
because the legacy build machine doesn't have the right dependencies
installed - and we probably don't want to re-engineer those deployments
too heavily anyway.
Moving this to the `build-tarball` script and reverting the `Makefile`
changes lets us make things work the way they need to for Juju
deployments, while fixing legacy deployments.
