After analyzing all 218 CodeQL alerts across the project's history, the
workflow has not justified its CI cost:
- The most impactful query (PotentiallyDangerousFunction) was a custom
systemd-specific query that has already been replaced by clang-tidy's
bugprone-unsafe-functions check (6fb5ec3dd1).
- Of the remaining C++ queries, 6 never triggered at all
(bad-strncpy-size, unsafe-strcat, unsafe-strncat,
suspicious-pointer-scaling, suspicious-pointer-scaling-void,
inconsistent-null-check).
- Several high-value-sounding queries had extreme false positive rates:
toctou-race-condition (95% FP), use-after-free (88% FP),
cleartext-transmission (100% FP).
- Many queries that did trigger are already covered by compiler warnings
(-Wshadow, -Wformat, -Wunused-variable, -Wreturn-type,
-Wtautological-compare) or existing clang-tidy checks
(bugprone-sizeof-expression).
- Across all alerts, only 3 genuinely useful C++ fixes can be
attributed to CodeQL: 1 tainted-format-string, 2
incorrectly-checked-scanf. The rest were either false positives or
incidental fixes during refactoring that weren't prompted by CodeQL.
- The Python queries are largely superseded by ruff (already in CI) and
had an 89% false positive rate on the security-focused checks.
The workflow consumed significant CI resources (40+ minutes per run) and
the ongoing maintenance burden of triaging false positives outweighs the
marginal value of the 2-3 real findings it produced across its entire
lifetime.
Currently, to run the integration tests, it's still necessary to
install various other build tools besides meson: A compiler, gperf,
libcap, ... which we want to avoid in CI systems where we receive
prebuilt systemd packages and only want to test them. Examples are
Debian's autopkgtest CI and Fedora CI. Let's make it possible for
these systems to run the integration tests without having to install
any other build dependency besides meson by extracting the logic
required to run the integration tests with meson into a separate
subdirectory and adding a standalone top-level meson.build file which
can be used to configure a meson tree with as its only purpose running
the integration tests.
Practically, we do the following:
- all the integration test directories and integration-test-wrapper.py
are moved from test/ to test/integration-test/.
- All the installation logic is kept out of test/integration-test/ or
any of its subdirectories and moved into test/meson.build instead.
- We add test/integration-test/standalone/meson.build to run the
integration tests standalone. This meson file includes
test/integration-test via a cute symlink hack to trick meson into
including a parent directory with subdir().
- Documentation is included on how to use the new standalone mode.
- TEST-64-UDEV-STORAGE and TEST-85-NETWORK are changed to generate separate
units for each testcase to make them behave more like the other integration
tests.
Since 56b2970 has proven to be a no-go for us, as it breaks existing
links, let's embrace the trailing slash and use absolute links
everywhere for our pages. This way we'll get around browser cleverly
appending the relative link to the current location (since it ends with
a slash), and given our docs/ layout is flat it's not much of a hassle
either.
Converted using this beauty:
$ sed -ri 's/(\[.+\]\()([A-Z_]+\))/\1\/\2/g' *.md
Resolves: #32088 (again) and #32310
This reverts commit 5e8ff010a1.
This broke all the URLs, we can't have that. (And actually, we probably don't
_want_ to make the change either. It's nicer to have all the pages in one
directory, so one doesn't have to figure out to which collection the page
belongs.)
With meson-0.60, meson compile stopped working with some targets:
$ meson compile -C build update-man-rules
ERROR: Can't invoke target `update-man-rules`: ambiguous name. Add target type and/or path: `PATH/NAME:TYPE`
This is obviously a regression in meson, but based on a chat with the
maintainers, it seems that there's some disagreement as to whether 'meson
compile' is useful and how exactly it should work. Since we're already at
meson 0.60.3 and this hasn't been fixed, and people generally don't seem to
consider this an issue, let's return to documenting the usual practice of
'ninja -C build' that just works everywhere.
(Since nobody has raised any fuss in systemd, it means that people are
generally using the shorter form during development too. I only noticed
because I pasted a command from the release docs when preparing -rc1.)
I have no idea if this is going to cause rendering problems, and it is fairly
hard to check. So let's just merge this, and if it github markdown processor
doesn't like it, revert.
This only changes documentation. In various places we call "ninja"
directly. I figured it would be safer to leave those in place for now,
given the meson replacement commands lines appears to be supported in
newer meson versions only.
It turns out Jekyll (the engine behind GitHub Pages) requires that pages
include a "Front Matter" snippet of YAML at the top for proper rendering.
Omitting it will still render the pages, but including it opens up new
possibilities, such as using a {% for %} loop to generate index.md instead of
requiring a separate script.
I'm hoping this will also fix the issue with some of the pages (notably
CODE_OF_CONDUCT.html) not being available under systemd.io
Tested locally by rendering the website with Jekyll. Before this change, the
*.md files were kept unchanged (so not sure how that even works?!), after this
commit, proper *.html files were generated from it.
The docs/ directory is special in GitHub, since it can be used to serve GitHub
Pages from, so there's a benefit to switching to it in order to expose it
directly as a website.
Updated references to it from the documentations themselves, from the
CONTRIBUTING.md file and from Meson build files.
Daan De Meyer
Yu Watanabe
Emmanuel Ferdman
Daan De Meyer
Frantisek Sumsal
Zbigniew Jędrzejewski-Szmek
hulkoba
Dmitry V. Levin
Evgeny Vereshchagin
Benjamin Franzke
Lennart Poettering
Tobias Bernard
Filipe Brandenburger