| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
The tag we actually use already contains a hash of the input files and
is generated (by `ci-fairy generate-templates`). There is no need for having
this fixed prefix. As also seens by having a date there, which is maintained
badly and meaningless.
Drop it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have many test configurations (i.e. distros like fedora:37,
debian:9). Almost all of them run manually triggered, because running
them every time would be wasteful.
Still, even as we trigger those tests only seldom, whenever we trigger
them all together, they consume still too many resources of the
freedesktop.org gitlab infrastructure.
One possibility would be to just drop old distros (e.g. fedora:30).
Which tests are setup in gitlab-ci is constantly refined and adjusted.
So dropping some distros is not necessarily wrong and bound to happen
eventually.
However, I also don't find it great to just disable tests that are still
passing. If we want to avoid consuming too many resources, we can just
choose not to run those tests. We don't need to enforce that by deleting
tests. Once deleted, such a configuration cannot be tested anymore as it
would be too cumbersome to recreate the setup manually.
Instead, introduce stages/tiers to clearer mark configuration that we
should test even less frequently.
Note that it is still required from the developer to not trigger too
many tests at once, to not monopolize the CI resources. The stages
should make that clearer to see, but don't solve it. Deleting tests
might solve it, but only if we delete a significant number of those
tests, which seems not desirable.
|
| |
|
|
|
|
|
|
|
|
| |
We want to follow current Fedora, so update to f37.
Also, we now use clang-format from Fedora 37 release, so the default
image in gitlab-ci must match, because that image is used for the
"check-tree" test.
|
| |
|
|
|
|
| |
Fixes: 9570224e86c4 ('tests/client: add a pexpect-based test runner')
|
|
|
|
| |
gitlab-ci to f36
|
|
|
|
|
| |
It's sad, old and unsupported. Also its gettext is old and smells of
elderberries.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
ci-templates now works around the earlier problem to install CentOS 8
Linux containers. Re-add the tests.
This reverts commit b2d2b8d6fa05e6911c3a7599b35e38e149ddf873.
|
|
|
|
|
|
|
| |
We need the latest fix to bootstrap CentOS 8 Linux containers.
See-also: https://gitlab.freedesktop.org/freedesktop/ci-templates/-/merge_requests/131
See-also: https://gitlab.freedesktop.org/freedesktop/ci-templates/-/merge_requests/132
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CentOS 8 Linux is end of life. That wouldn't bother us, but when
you start such a container
$ podman run -ti --privileged quay.io/centos/centos:8.3.2011
then `dnf upgrade` will fail, because the mirror list returns
nothing. To work around that, we need to adjust ci-templates ([1]).
The work around might be to patch /etc/yum.repos.d when creating
the container image ([2]).
For now (or maybe indefinitely) disable these build targets.
[1] https://gitlab.freedesktop.org/freedesktop/ci-templates/-/merge_requests/131
[2] https://stackoverflow.com/questions/70926799/centos-through-vm-no-urls-in-mirrorlist
|
| |
|
| |
|
|
|
|
|
| |
There was a problem that the containers didn't correctly build.
That is now fixed. Reenable f35 and f36 (rawhide).
|
|
|
|
|
|
| |
These containers are ancient. Also, when we update ci-templates
they will no longer build (because then a different container hub
will be used, which doesn't contain those images). Drop them.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It fails to install the container. Disable it, until it is more
stable.
...
Install 363 Packages
Total download size: 275 M
Installed size: 1.1 G
Downloading Packages:
python3: allocatestack.c:191: advise_stack_range: Assertion `freesize < size' failed.
./contrib/fedora/REQUIRED_PACKAGES: line 17: 815 Aborted $NM_INSTALL "$@"
subprocess exited with status 134
subprocess exited with status 134
exit status 134
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This results in a rebuild of the containers, which is a good idea as we
didn't do that for a while.
|
|
|
|
|
|
|
|
|
| |
- the container that is also "pages_build" should always
run automatically. This can replace the "always" tag.
- comment out the "always: 33" part, because we no longer need
it. It was also wrong, because by now we should run Fedora 34
automatically.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- the python-black version on Fedora 33 was updated, and this formats
our python code differently. The black version that is used by our
gitlab-ci is the authoritative version that should be used. Update
it by regenerating the containers.
- especially Fedora:rawhide and Debian:sid often introduce changes that
will cause a break of our build. Update the containers to test latest
versions.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Alpine is especially interesting because it uses musl as libc.
The build does not yet succeed. There are several issues that
need to be fixed.
However, it will be simpler to fix things, if we have tests
in place -- even if at the moment they are known to be broken.
See-also: https://git.alpinelinux.org/aports/tree/community/networkmanager?h=master
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ci-templates builds and caches the test containers. When the build
scripts, the ci-template or "config.yml" changes, we need to bump
the tag so that the containers get rebuild.
Partly automate this. The tag now gets generated by the template and
contains a checksum of certain build files. Thus, if you change
any build files, then `ci-fairy generate-template` would generate a
different tag. You can not miss that, because we have tests that ensure
that our ".gitlab-ci.yml" is up to date. Also, you no longer need to
manually bump the tag when a build script changes, just regenerate
".gitlab-ci.yml" with `ci-fairy generate-template`.
See also: https://gitlab.freedesktop.org/freedesktop/ci-templates/-/merge_requests/54
|
| |
|
| |
|
|
|
|
| |
That is now the one that generates the pages and runs checkpatch stage.
|
|
|
|
|
|
|
|
|
|
|
|
| |
On one image we do extra work, like generating documentation (gitlab-pages).
The same image is currently also used for the "checkpatch" step. That step
checks code formatting using clang-format. The formatting depends on the
clang version, and we currently choose Fedora 33 as the desired version
for formatting.
It means, the "checkpatch" step requires Fedora 33. We could choose a
different image for generating pages and run check patch. However, that
might not be best. Just also generate the pages using Fedora 33.
|
|
ci-templates encourages building specific containers that can be re-used:
- containers are re-used across pipelines, producing consistent results
- containers are re-used by contributors since they will use the upstream
containers for their MR, thus guaranteeing the same results.
Containers are automatically rebuild whenever the respective
FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that
Docker Hub will introduce pull limits.
This CI script consists of a config file and a jinja2 template, simply
running 'ci-fairy generate-template' produces the .gitlab-ci.yml.
ci-fairy is part of the freedesktop.org ci-templates and can be pip
installed, see the check-ci-script job.
Functional changes to the previous script:
- new job: check-ci-script, verifies that our gitlab-ci.yml is the one
generated by the sources
- Added distributions:
- Fedora 33
- The actual work is now down by a set of scripts in .gitlab-ci/,
specifically:
- .gitlab-ci/build.sh is the previous do_build job
- .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs
symlinks are in place for centos and ubuntu
Why the scripts instead of steps in the CI? Easer to reading and
reproduce. With the containers being static, it's easy to pull one
locally and re-run the CI job to reproduce an issue. Having everything in a
single script makes that trivial.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
|