summaryrefslogtreecommitdiff
path: root/.gitlab-ci.yml
Commit message (Collapse)AuthorAgeFilesLines
...
* gitlab-ci: bump tag for cached container imagesThomas Haller2021-06-231-5/+5
| | | | | This results in a rebuild of the containers, which is a good idea as we didn't do that for a while.
* gitlab-ci: fix error evaluating "distro.always" in ci.templateThomas Haller2021-05-261-5/+5
| | | | | | | | | | | ... File "/usr/local/lib/python3.9/site-packages/jinja2/environment.py", line 1361, in generate yield self.environment.handle_exception() File "/usr/local/lib/python3.9/site-packages/jinja2/environment.py", line 925, in handle_exception raise rewrite_traceback_stack(source=source) File ".gitlab-ci/ci.template", line 178, in top-level template code {% if not version in distro.always and (distro.name != pages_build.name or version != pages_build.version) %} jinja2.exceptions.UndefinedError: 'dict object' has no attribute 'always'
* Revert "contrib: no longer install libuuid as build dependency"Thomas Haller2021-05-261-4/+4
| | | | | | | | | | | | Ups, we actually still require libuuid. Actually, we only need to to build the example script `examples/C/glib/add-connection-gdbus.c`. The proper solution would be to make this an optional dependency. So far this was not yet done. Also, libuuid is really an ubiquitous dependency on Linux, so it's not really a problem to have this build dependency, even if it's just to build the examples. This reverts commit c0a3947ff9571b0b36b3c1acc358ea7d8599afa9.
* gitlab-ci: belatedly regenerate `.gitlab-ci.yml`Thomas Haller2021-05-261-4/+4
|
* gitlab-ci: fix running Fedora 34 test by defaultThomas Haller2021-05-041-7/+10
| | | | | | | | | - 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.
* gitlab: update pages build to use Fedora 34 containerThomas Haller2021-05-041-10/+10
|
* gitlab: add Fedora 34 container for CI pipelineThomas Haller2021-05-041-5/+35
|
* contrib: install clang-format via REQUIRED_PACKAGESThomas Haller2021-05-041-2/+2
| | | | | | | | On Fedora 33, we get it automatically because "clang" package has an indirect (weak) dependency for clang-tools-extra. On Fedora 34, that is no loger the case. We need to explicitly install it.
* gilab-ci: update .gitlab-ci.yml to use "main" branch nameThomas Haller2021-04-011-6/+6
|
* gitlab-ci: generate new container images for testsThomas Haller2021-01-281-5/+5
| | | | | | | | | | | - 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.
* gitlab-ci: install missing packages on Alpine LinuxThomas Haller2020-12-231-1/+1
| | | | | | The "contrib/alpine/REQUIRED_PACKAGES" script is also used by gitlab-ci to setup the test container. These packages are required for unit tests.
* gitlab-ci: enable test build on alpine linuxThomas Haller2020-12-111-4/+40
| | | | | | | | | | | | 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
* gitlab-ci: update used "ci-templates" versionThomas Haller2020-12-111-5/+5
|
* gitlab-ci: fix failure to enable PowerTools on CentOS8 buildThomas Haller2020-12-111-2/+2
| | | | | Seems that the repository was renamed (or can sometimes have a different name). Try both the "PowerTools" and "powertools" name.
* all: avoid GNU "which" from shell scriptsThomas Haller2020-12-111-2/+2
| | | | | | "which" is a separate package and may not be installed. Also, shell has a built-in command for the same purpose. Use that.
* gitlab-ci: add CentOS 7.9 and 8.2 imagesThomas Haller2020-11-241-4/+64
|
* gitlab CI: remove leftover comments referring to libinputPeter Hutterer2020-11-181-6/+5
| | | | | | Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/684
* gitlab-ci: combine ubuntu/centos install scripts with their debian/fedora ↵Thomas Haller2020-11-171-6/+6
| | | | | | | | | | | | | | | | | | counterparts Ubuntu/Debian and CentOS/Fedora are sufficiently similar that it's better that we have only one variant of ".gitlab-ci/*-install.sh" and "contrib/*/REQUIRED_PACKAGES". This was already the case, however, we used to symlink ".gitlab-ci/centos-install.sh" to "fedora-install.sh". That worked, but it didn't scale very well. For example, if we would follow that pattern, we would also need a symlink "contrib/centos/REQUIRED_PACKAGES" Or should "contrib/centos" symlink to "contrib/fedora"? That seems even more wrong. We already had the "distro.base_type" variable for that. Make use of that also for the install script.
* gitlab-ci: install correct version of ci-templates in build scriptThomas Haller2020-11-171-2/+2
| | | | | | | It's not clear that ci-fairy has a stable API. Instead, we pin the version by specifying the git commit sha. In the build script, install the pinned version.
* gitlab-ci: automatically hash build scripts into tag for ci-templates containerThomas Haller2020-11-171-5/+5
| | | | | | | | | | | | | | | | 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
* gitlab-ci: automatically run prep-container to fix hanging testsThomas Haller2020-11-111-20/+20
| | | | | | | | | | | | | | The goal is to run most distros only manually. However, it would be nice to avoid (manually) clicking twice to start the tests for one distro: once for the container preparation, and once for the actual test. Previously, the container prep part was set to manual and the actual test automatic. It worked almost as desired, except that this leads to the entire gitlab-ci pipeline be be in running state indefinitely. To fix that, always run the container prep steps. If the container is cached, this is supposed to be fast and cheap. Now only the actual tests are marked as "manual".
* gitlab-ci: add "needs" for pages testThomas Haller2020-11-111-0/+2
| | | | | | It seems "pages" test does not get properly triggered, if only t_fedora:33 completes. It should, because the other distros are optional. Try to set "needs" to fix that.
* gitlab-ci: fix building artifacts (pages) during gitlab-ci testThomas Haller2020-11-101-0/+4
|
* gitlab-ci: bump default-tagThomas Haller2020-11-101-4/+4
|
* gitlab-ci: merge "check-ci-script" test with static checksThomas Haller2020-11-101-23/+16
| | | | | | | | | | | | | | | | | | | | | | Certain parts of the code are entirely generated or must follow a certain format that can be enforced by a tool. These invariants must never fail: - ci-fairy generate-template (check-ci-script) - black python formatting - clang-format C formatting - msgfmt -vs On the other hand, we also have a checkpatch script that checks the current patch for common errors. These are heuristics and only depend on the current patch (contrary to the previous type that depend on the entire source tree). Refactor the gitlab-ci tests: - split "checkpatch" into "check-patch" and "check-tree". - merge the "check-ci-script" test into "check-tree".
* gitlab-ci: don't explicitly install black/clang/gettext during checkpatch stageThomas Haller2020-11-091-1/+0
| | | | | "checkpatch" is based on the default image (currently fedora:33). It already has these dependencies installed.
* gitlab-ci: add ubuntu:20.04 test and reorder versionsThomas Haller2020-11-091-72/+102
|
* gitlab-ci: let Fedora 33 test always runThomas Haller2020-11-091-1/+1
| | | | That is now the one that generates the pages and runs checkpatch stage.
* gitlab-ci: generate pages on Fedora 33 imageThomas Haller2020-11-091-3/+3
| | | | | | | | | | | | 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.
* gitlab-ci: reorder jobs for checkpatch testThomas Haller2020-11-091-1/+1
| | | | | | | | | | | | | All the steps of "checkpatch" test (except the last) check the current tree for consistency. Those checks must always pass. Only the last step calls the "checkpatch-feature-branch.sh". That script checks for common patterns, like avoiding g_assert() (in favor of other assertion types). That last check only checks the current patch, and there are many cases where the test is known to fail (because these are just heuristics). As such, the step that may fail should be called as last.
* gitlab CI: switch to using ci-templatesPeter Hutterer2020-11-091-166/+714
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* gitlab-ci: combine tests for checkpatch/black/msgfmt and nm-code-format.shThomas Haller2020-09-291-19/+4
| | | | | | | | | | | | | | There is no need spawn up two containers (and install similar packages, doing so is resource intensive), to run two different tests. We can run them in the same container. At this point Fedora 33 is not yet fully released. But it will happen soon, so the image is stable enough for these kinds of tests (and will only get more stable in the following weeks). Also no longer collect an artifact with the test output. The test output is already nicely visible in the gitlab-ci UI. No need to collect it separately.
* gitlab-ci: add clang-format test on fedora 33 which run clang-format 11Antonio Cardace2020-09-281-0/+12
| | | | Signed-off-by: Antonio Cardace <acardace@redhat.com>
* gitlab-ci: add test for checking po filesth/po-fix-fr-ja-zh_CNThomas Haller2020-09-041-1/+2
|
* gitlab-ci: fix workarounds for Ubuntu 16.04 in testsThomas Haller2020-08-281-2/+2
| | | | | | | The detection for Ubuntu 16.04 was broken. By now /etc/os-release contains VERSION="16.04.7 LTS (Xenial Xerus)"
* gitlab-ci: enable fedora:33 build and generate pages on F32Thomas Haller2020-08-181-3/+9
|
* gitlab-ci: check "examples/python/gi/nm-wg-set" with blackThomas Haller2020-07-021-1/+1
|
* gitlab-ci: enable python black check in gitlab-ciThomas Haller2020-06-191-1/+2
|
* gitlab-ci: run checkpatch test against fedora:32 targetThomas Haller2020-06-191-1/+1
|
* gitlab-ci: avoid signing release build in gitlab-ciThomas Haller2020-06-071-1/+1
| | | | The environment has no GPG key configured, so trying to sign fails.
* gitlab-ci: add more CentOS images for testsThomas Haller2020-05-141-5/+26
|
* gitlab-ci: use old meson version on Ubuntu 16.04 to work with ninja-1.5.1Thomas Haller2020-04-021-1/+2
| | | | | | | | | | | | | | | | | | | | Meson 0.54.0 requires ninja-1.7 ([1]). On Ubuntu 16.04, we now would get meson 0.54.0 via pip3, but ninja-1.5.1 via apt. That doesn't work anymore. We could install ninja via pip3, but of course, doing that on other Debian/Ubuntu versions fails due to ... I don't even want to know. So, instead use an old meson version on Ubuntu 16.04, which is known to still work with the ninja provided by the packaging system. We anyway don't want to test the same meson/ninja versions on all our Ubuntu/Debian images. The point of having different images is to build with different software versions. If `pip3 install` gives us the same everywhere, it isn't very useful. https://mesonbuild.com/Release-notes-for-0-54-0.html#ninja-version-requirement-bumped-to-17
* gitlab-ci: set DEBIAN_FRONTEND=noninteractive for `apt-get install`Thomas Haller2020-04-021-2/+2
| | | | | Otherwise, installing a package might prompt for the user to type something, breaking the CI build.
* gitlab-ci: use ruby:2.7 for triage pipelineAntonio Cardace2020-03-181-1/+2
| | | | | | | This fixes the pipeline as 'gem' will be installed by default in the container image. Also fix wording and run gitlab-triage in debug mode to get more output.
* gitlab-ci: add scheduled pipeline to triage inactive issues and MRsAntonio Cardace2020-03-181-0/+9
|
* gitlab-ci: fix deploying documentation after switching to Fedora 31Thomas Haller2020-02-221-1/+1
| | | | Fixes: ec8068ec0c73 ('gitlab-ci: add "t_fedora:32" and by default build on Fedora 31')
* gitlab-ci: add "t_fedora:32" and by default build on Fedora 31Thomas Haller2020-02-211-2/+8
|
* gitlab-ci: fix generating "pages" after switching to Fedora 30 for main buildThomas Haller2019-12-131-1/+1
| | | | (cherry picked from commit c15682558cdedac404f97ea74ebf53317d9f1681)
* gitlab-ci: run tests on extra distributions only manuallyThomas Haller2019-11-221-0/+8
| | | | | | | | | | | For the moment, we use docker images from dockerhub, which require a lot of extra overhead to prepare and install the test environment. This should be improved, by using more suitable container images. Anyway, for now to alleviate the pressure on the freedesktop gitlab infrastructure, disable most test to only run manually. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/241#note_282521
* gitlab-ci: use Fedora 30 to build documentation and archived tarballThomas Haller2019-11-221-5/+5
|
View Lorry Controller Status