The special sha is no longer needed, let's bump to a recent version of
hugo instead and that should make it all work nicely (for a while).
Updating hugo requires changing to hugo.toml and forcing mermaid to be
enabled, without those changes the build failed with
`failed to extract shortcode: template for shortcode "mermaid" not found`
This reverts commit 5909717700
Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/358>
This is primarily a development feature because it makes it easier to
develop a new feature for just one library without having to worry
about build errors in the other library (e.g. when new protocol parts
are added).
Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/310>
This drops one dependency that we're not fully using anyway. Except for
the per-attribute validators that can be done in __post_init() we're not
using attrs for anything that dataclasses cannot do.
F40 now ships v0.121 which again breaks something in the relearn theme
so let's lock our version here to one we know works and move on with
life. I can't be bothered to relearn hugo and themes every few months
just for a single static website.
And drop the job to test the minimum meson version in the process. F39
ships with python 3.12 which causes this error with meson 0.56.0
proto/meson.build:17:0: ERROR: <ExternalProgram 'python3' -> ['/usr/bin/python3']> is not a valid python or it is missing setuptools
We could put the effort into setting up the CI to fix this, but we
won't.
The pages job is only run once we push to main, so any issues with the
documentation build won't be picked up until it's too late. Split those
up and build the doc in a separate job, the pages job simply takes the
artifacts from that job and publishes them.
The ABI job git cloned from upstream and then compared HEAD with the
last ABI break. Problem though: the HEAD was origin/main, not the actual
HEAD from the merge request.
Fix this by adding upstream as a remote and fetching from it. And while
we're there update to the last ABI break commit sha and move the
abicheck bits into before_script.
Note that the remote has the CI job ID appended, this avoids conflicts
when the git repo is re-used betweenn jobs and the upstream remote
already exists.
Since meson is installed from pip, we'll use the latest stable version
when we build an image. Add an extra job with the fixed minimum version
so we ensure we actually build with that version.
The protocol name on an interface is a fixed string that is part of
the ABI since it's used in a few messages (e.g.
ei_handshake.interface_version). To avoid typos, let's expose that
string in the scanner and #define it in the generated sources.
Since we want the generated documentation to be useful on-disk, drop the
baseURL and switch to relativeURLs = true for hugo.
This is arguably a bit nasty in that it git clones the theme into the
build directory. But oh well...
Embarassingly, only the valgrind test would actually run tests because
it was the only one with a non-null MESON_TEST_ARGS. Let's fix this by
explicitly telling the build script to run the tests.
Because we currently only run the test suite in valgrind, we skip the
python test suite there (we don't want to valgrind python itself, too
messy).
Fix this by specifically excluding the python test suite and having a
separate job that just runs that suite instead.
And because the protocol test suite needs the directory to the
eis-demo-server and isn't smart enough to split spaces correctly, let's
change the builddir to just that.
This tests the protocol layer which is hard to test using libei/libeis.
Similar to the generated C bindings we compile a eiproto.py file that is
then used in the test to talk protocol directly to the eis-demo-server
that we start up.
By sending the specific messages and checking things happen as we expect
on the socket we can verify that the EIS implementation is correct (and
robust enough).
In theory this could also be used to test some other binary with an EIS
implementation and the scaffolding is there to set LIBEI_TEST_SERVER to
that binary. Wether this works is untested though...
The venv is needed now because black now requires a newer 'packaging'
and fails to installed with:
ERROR: Cannot uninstall 'packaging'. It is a distutils installed
project and thus we cannot accurately determine which files belong to
it which would lead to only a partial uninstall.
So let's use a venv and while we're doing this switch to use the
ci-fairy image so we don't need to worry about docker limits.
