Versions that has branched out from Rawhide but are still not released
still have many changes that breaks the CI.
As we want the CI to be more stable for Tier 1, which runs for every MR,
do not make the switch as soon as Rawhide has branched, but when we choose so.
I always struggle to understand what 'check_run' means, as it suggests
that the run is executed and the results checked. What it acutally does
is to check if the run passed as argument is selected. Rename to
is_run_selected.
Also, remove check_run_clean which was only a check_run + do_clean. Just
call directly to do_clean.
Add option --all to distros_support.py to show all the NM versions that
are being actively used by any active distro. This will be useful to
decide what stable branches are we interested into actively backporting
fixes and which ones we're not.
Passing a version number of NetworkManager to this new script, it prints
what distros are using that NM version and generates a new content for
.gitlab-ci/config.yml.
Automatically generating the config.yml content is useful because we can
easily update what distros we test in the CI and the Tier that they
belong, depending on what version of NM do they ship and whether they
have reached EOL or not.
Important: when generating a config.yml for an stable branch, not for
main, it must be generated from main. This is because we are not going
to keep distros-info.yml up to date in all branches, only in main.
Useful to have easily accessible the info of all the distros that we
test, including the version of NM that they ship and their EOL dates so
we can know when to stop testing them.
For now this is only informative, but we can use this info, for example,
to generate the `.gitlab-ci/config.yml` file automatically for each
stable branch.
We currently submit builds to Coverity manually every now and then,
but it would make sense to submit them more frequently and periodically,
so that it can detect defects sooner.
Add a "coverity" stage to the pipeline, which submits a build to Coverit
(the scheduls currently set to run every week).
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1973
Add explanation of how to indicate the new issues workflow to
MAINTAINERS.md: triage -> investigation -> devel. The different
stages are indicated using Gitlab's scoped labels (mutually exclusive).
These stages try to hightlight that the issue cannot be fixed and it's
not moving forward because more info is needed, already. Also, add a
section to CONTRIBUTING.md highlighting the importance of helping in
the triage and investigation stages: developers often cannot fix bugs
because lack of time to investigate, but even users that doesn't know
how to fix it due to lack of knowledge of the code base can help thanks
to their knowledge on networking.
Finally, make the 'triage:issues' CI job to work again, adding some
new policies with new automations. The automation will add or remove the
labels: stale, help-needed::{triage, investigation, devel} and
unassigned.
The labels help-needed::* and unassigned will be automatically added to
all issues without an assignee. This reflects better the reality of not
having enough time to work on most of the issues unless there is some
external help.
As Fedora 41 (currently Rawhide) is migrating to DNF5 [1], the
debuginfo-install command is not available anymore according to the
documentation. Instead, the user need to add the package suffix
"-debuginfo" when using the install command.
The implementation of the debuginfo-install plugin is under development
and tracked upstream. [2]
[1] https://fedoraproject.org/wiki/Changes/SwitchToDnf5
[2] https://github.com/rpm-software-management/dnf5/issues/389
This job was supposed to run periodically. However, it stopped working
when a "workflow" section was added to .gitlab-ci.yml because it
prevented pipelines of the type "scheduled" to be created.
7fa72645e5 ('gitlab-ci: make detached MR pipeline for external contributor's pipelines to run')
Now, if it's run, it fails with error:
multi_xml requires Ruby version >= 3.1.4. The current ruby version is 2.7.8.225.
Let's disable the job until we fix it and we decide what triage we want
to do. When we do it, we will need to adapt the jobs to be run with the
right periodicity, maybe using custom pipeline variables.
This will force to regenerate the various images of the distributions
that we want to test so we get an updated snapshot on them. Otherwise we
might be testing a months old version of them.
A bug in ci-fairy was making the deletion of the images to partially
fail. It is fixed in the latest version of ci-fairy, so we need to
update the value of templates_sha to pick it.
The task will run only on pipelines of type "scheduled". Then we can
create a weekly scheduled pipeline in Gitlab.
We had an agreement on what distributions should we test and when. We'll
test in Tier 2 those distros that can potentially use the current
version of NM and in Tier 3 those distros that are still maintained (not
EOL'd).
So, Tier 2 is to catch errors that might be severe because might be
blocking for the distributions planning to use the current NM version,
they must be fixed ASAP, before doing the release if possible. These
"distribution versions" will be different for main branch than for
stable branches:
- Debian 12 uses NM-1.42, so Debian 12 should be Tier 2 in the branch
nm-1-42.
- However, Debian 12 will never use newer stable versions, so it should
be Tier 3 in main branch.
We want to run the Tier 3 tests even if those distros won't use newer
vesions of NM because they are useful to test NM compilation with older
compilers and tools. Fixing failures here might not be considered
urgent, though.
To save resources from Freedesktop we'll run Tier 1 on every MR and
Tiers 2 and 3 before doing a release, or on demand if we need.
The test "tarball+meson" fails on systems with old meson version with
the message "ERROR: Neither directory contains a build file
meson.build". This message is raised when calling `meson dist` from the
build directory.
According to meson documentation, `meson dist` is supported since 0.52,
and older vesions need to execute `ninja dist`.
https://mesonbuild.com/Creating-releases.html
Also, when using meson.add_dist_script, the env variable MESON_SOURCE_ROOT
is not passed in versions < 0.54. As we don't use it in the script,
don't assert for it.
We claim to support down to meson 0.47.3 (we need to raise it because we
are actually using a bit newer features, but that's another topic). Use
`ninja dist` that will work fine on old and new meson.
Fixes: 61f0531509 ('gitlab-ci: test re-buildability of distribution tarballs')
Some warnings in the generation of the translation files indicate real
errors, like strings that cannot be extracted for translations. Check
that no warnings are emitted.
- after modifying .gitlab-ci, the template must be regenerated by
running `ci-fairy generate-template`
- when swapping tier1 from f38 to f39, the list in tier2 must be updated
too.
Fixes: e2f04f0d2cc3 ('device: fix generated 'wifi.cloned-mac-address="stable-ssid"' for stable-id')
As Fedora 39 is officially out, we should use it in our gitlab-ci.
Please notice that this change will also update the
nm-code-format-container.sh to use Fedora 39 aswell.
CentOS Linux 8 is long gone. We were only running tests on this old
build environment, to see how we fare in such environment.
The test was broken for 4+ months. Instead of fixing it, disable it.
It's partly caused by RHEL8, as it is somewhat cumbersome to even build
on CentOS 8. That's because some devel packages (like libteam-devel) are
not installable. As workaround for that, we re-build such packages in a
copr ([1]). The problem is, that we only have one copr build for e.g.
CentOS 8. If we rebuild against latest CentOS 8 Stream, then libteam is
build against newer dependencies, which are not installable on CentOS
Linux 8.1.1911 (etc). We would have to build libteam in a way, that
does not drag newer dependencies that are missing on CentOS Linux 8.
For example, trying to use copr [1] on CentOS Linux 8 and installing
"teamd" gives:
Error:
Problem: package teamd-devel-1.31-4.el8.x86_64 requires teamd = 1.31-4.el8, but none of the providers can be installed
- conflicting requests
- nothing provides libjansson.so.4(libjansson.so.4)(64bit) needed by teamd-1.31-4.el8.x86_64
This could be hacked around, for example by having libteamd-devel not
depend on any teamd package. Instead, just drop it. It's gone.
Arguable, CentOS 8 Stream should be reasonably close (in terms of
versions of gcc, glibc, glib) so we don't miss too much.
[1] https://copr.fedorainfracloud.org/coprs/nmstate/nm-build-deps/https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1793
Now that we no longer test on CentOS7, we also have no more tests that
build using Python2.
Note that build with Python2 is currently broken already (which would be
fixable).
Drop Python2 too.
Existing Python scripts still use a common subset of Python2 and
Python3. They can be improved to use Python3 features in the future.
CentOS7 uses gcc-4.8, which have various problems and working around
them is getting more cumbersome.
Also, CentOS7 is ancient by now. It's time. Drop it.
We don't use "rawhide", because we explicitly enable Fedora versions by
their release number (and "rawhide" is just an alias).
However, by now "rawhide" is Fedora 40. Enable it.
Debian:9 (stretch) is archived. We need to patch the sources.list
for it to be usable.
Although it's end of life, we are still interested, whether we
are able to build with such old compiler. Fix the test.
Debian 9 (stretch) is end of life, and the repositories are archived. We
need to patch the containers so that `apt-get update` continues to work.
A new ci-templates version brings that.
Note that at the moment, there is still another issue for debian:9
containers. Unclear whether that can be fixed. In any case, bumping to
latest ci-templates is not wrong, and works around the first issue on
debian:9, making it possible to at least look at the second issue.
https://gitlab.freedesktop.org/freedesktop/ci-templates/-/merge_requests/175
We want to follow current Fedora, so update to Fedora 38.
Also, we now use clang-format from Fedora 38 release, so the default
image in gitlab-ci must match, because that image is used for the
"check-tree" test.
While at it, add Fedora 39 and move Fedora 36 to tier 3.
These stages were not properly implemented and don't seem to work.
Drop them.
Note that we do want that our cached containers get collected eventually.
As these are just caches for performance reasons, that could be done with
little downsides (we can just regenerate the containers when we need them).
However, that's not done by our gitlab-ci stages. Instead, it should
be done on a project level. It's not clear whether that is actually done,
but if there is a need (because of the resources that this wastes), then
we should do that (on freedesktop.org's gitlab instance).
We want that the tier2+ tests are only run manually. As those tests
depend on the respective prep step, there are 3 possibilities:
1) make prep manual and the tier test automatic. That is what we would
want, because then we can just manually trigger the prep step (one
click). However, in the past this didn't work.
2) make the prep automatic and the test manual. That works, the downside
is that we often run the prep step when its not needed. This is what
we used to do to workaround 1).
3) make prep and the test manual. Then there are no unnecessary tests
run, but triggering a manual test is cumbersome. First click to start
the prep step, then wait, then click again.
Revisit this. It seems 1) is working now. Yeay.
Also rename the prep stages, so that it's clear to which tier they
belong. I guess, I could move them instead to prep1, prep2, prep3
stages, but then there are a lot of columns on the web site.
The distro.name is not just a pretty name, its the name under which we fetch
the container. It is thus a well-known name, that we can rely on.
The "base_type" only depends on the distro name, and it makes no sense
to ever choose a different name. Tracking it in the "distributions"
array is thus redundant.
Move the mapping of distro.name to the base type to a separate place.
