This allows us to drag in packages that replace something in the base
image. Notably, this fixes installing pppd on Fedora 42 that requires
systemd (whereas the image has conflicting systemd-standalone-sysusers).
(cherry picked from commit 979717df4e)
Old branches tend to be formatted with a different versions of
clang-format, so when patches are backported, they introduce some
differences in formatting, making the check-tree job to fail.
These changes in formatting are normally small, and we don't pay much
attention to them, causing that the pipelines are always red, increasing
the work required to check if there are important failures or not.
Make check-tree optional for branches other than main. This way,
failures will be shown as a "warning", and if a pipeline only shows a
warning we don't need to inspect it.
Previously, the coverity scheduled job seemed to fail
randomly because the image that it expected to use was
not available, due to not depending on the "prep" job.
This commit resolves the problem by making sure
the image is always built when coverity runs.
We only add to Tier 3 distro versions that ship a version of NM equal or
older to the one that we are testing. As CentOS Stream uses "main", no
stable version will be tested on it.
Force to test CentOS Stream as Tier 3.
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
