This pipeline features the following:
- Building of an nginx image with the XEPs as static files,
in all formats.
- Incremental builds on the main branch and incremental builds
for MRs based on the last main build.
- Automatic archiving of changed XEPs to the attic
- Automatic announcement to the mailing lists
If it is known that the documents have already been built or if it
is imperative to use the versions built even if local changes have
been applied since the last build, this switch comes in handy.
Most jobs depend on build or one of its subdirectories. By default,
this causes make to take the timestamp of the `build` directory (or
the respective subdirectory) into account when calculating whether
a job needs rebuilding.
This is a problem, because the modified timestamp of `build` updates
whenever a file is put into it. Effectively, this breaks incremental
builds.
Luckily, GNU(?) Make supports Order-only Dependencies, prefixed with
a pipe (`|`) symbol in the dependency list. That means that the
dependencies are not taken into account for freshness checks, but
will be built before the target (if they are non-fresh).
This commit introduces usage of Order-only Dependencies for the
output directories, which fixes incremental building.
While Blake2b is capable to produce digests of any size from 1 to 64 bytes, It's default mode is 64 bytes (512 bits) though.
Some libraries implement just default digest size.
* OpenSSL supports blake2s-256 and blake2b-512 (no blake2b-256)
* gcrypt supports both blake2b-256 and blake2b-512
* nss supports none of blake2b
* Botan - any digest size
* Java: https://github.com/alphazero/Blake2b - any digest size
* Go-lang: https://godoc.org/golang.org/x/crypto/blake2b - both blake2b-256 and blake2b-512
* Rust: https://docs.rs/blake2/0.8.1/blake2/ - any digest size, 512 by default
* JS: https://github.com/dcposch/blakejs - any digest size, 512 by default
Also various libraries based on openssl will provide just blake2b-512.
So it looks to be a preferable choice over blake2b-256
Since 'submit' type forms are allowed to omitt the explicit declartion
of the form field type, we must specify that the special FORM_TYPE
field in 'submit' forms may not carry a type declartion.
This just reflects what it is done in the wild anyways.
Co-authored-by: Marvin W <git@larma.de>
