Add Nix CI?
ferdnyc opened this issue · comments
Continuing/relocating the in-progress discussion from GSConnect/gnome-shell-extension-gsconnect#1370.
Seems like a good idea, although I'm not clear on what this will test. Would this be a smoke test for installation, or is just running the same tests on a NixOS image?
In any case, this should be pretty simple to organize by tagging gsconnect-ci:distro. In that way we can be a little bit clearer in the CI about what we're doing and throw them all in a build matrix to run in parallel. I also wouldn't be opposed to adding Ubuntu latest & LTS to the matrix.
Seems like a good idea, although I'm not clear on what this will test. Would this be a smoke test for installation, or is just running the same tests on a NixOS image?
More the former, plus a test that our tooling supports the needs of Nix packaging.
What this grew out of: Currently, Nix is patching meson_options.txt and installed-tests/meson.build like so:
diff --git a/installed-tests/meson.build b/installed-tests/meson.buildJan Tojnar, 2 years ago: • gnomeExtensions.gsconnect: 41 → 43
index c7eff2fb..ef4f6052 100644
--- a/installed-tests/meson.build
+++ b/installed-tests/meson.build
@@ -1,5 +1,5 @@
-installed_tests_execdir = join_paths(libexecdir, 'installed-tests', meson.project_name())
-installed_tests_metadir = join_paths(datadir, 'installed-tests', meson.project_name())
+installed_tests_execdir = join_paths(get_option('installed_test_prefix'), 'libexec', 'installed-tests', meson.project_name())
+installed_tests_metadir = join_paths(get_option('installed_test_prefix'), 'share', 'installed-tests', meson.project_name())
installed_tests_srcdir = meson.current_source_dir()
installed_tests_builddir = meson.current_build_dir()
diff --git a/meson_options.txt b/meson_options.txt
index 8912e052..ca6ee5eb 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -116,6 +116,13 @@ option(
description: 'Native Messaging Host directory for Mozilla'
)
+option(
+ 'installed_test_prefix',
+ type: 'string',
+ value: '',
+ description: 'Prefix for installed tests'
+)
+
option(
'installed_tests',
type: 'boolean',We could support that usage, for example with code like this in installed-tests/meson.build:
if get_option('installed_tests_prefix')
installed_tests_execdir = join_paths(
get_option('installed_tests_prefix'), 'libexec', 'installed-tests', meson.project_name())
installed_tests_metadir = join_paths(
get_option('installed_tests_prefix'), 'share', 'installed-tests', meson.project_name())
else
installed_tests_execdir = join_paths(
libexecdir, 'installed-tests', meson.project_name())
installed_tests_metadir = join_paths(
datadir, 'installed-tests', meson.project_name())
endif...but to prevent that option bitrotting, it should really be tested in the context of Nix builds.
I'm definitely not looking to go back to the days of having debian directories in every project source tree, or of upstreams trying to "own" the distro package control files locally. The official packaging would still be entirely the responsibility of the Nix, Fedora, Debian, etc. packagers.
But the CI environment presents an opportunity to set up test package builds in representative environments. So that (ideally) we can support the needs expressed (or demonstrated implicitly) by packagers, and have the distribution be package-able out of the box without them having to patch anything.
I figure the builds would still run the tests, just as a way of confirming success, but I don't expect there's any real value to be gained solely from replicating the internal tests onto every platform. We already know they're going to have pretty much the same results everywhere.
I also wouldn't be opposed to adding Ubuntu latest & LTS to the matrix.
I was thinking the same, though the version question gets kind of hairy.
For 6 months, every 2 years, their LTS and latest are the same. For much of the following 18 months until the next LTS, the release that's still their "current" LTS will still be on an older GNOME release that's no longer supported by the GSConnect main, since "GSConnect only supports the latest, stable version of GNOME." is a window much shorter that two years.
(To say nothing of the previous LTSes, since the 5-year support lifetime means there can be up to three "active" Ubuntu LTS releases at once.)
We could support that usage, for example with code like this in
installed-tests/meson.build:
I think that's totally fine, after all, NixOS is really the only distribution (that I know of) that actually needs to install GSConnect as a system package for it to work.
I was thinking the same, though the version question gets kind of hairy.
That's true, I guess the latest would be more than adequate for a smoke test. I think it's fair to say by now that no one's going to step up to maintain branches for our older releases. In any case, the LTS promise is really Ubuntu's burden to bear if they want to claim long-term support for a GSConnect package.
With a little re-organization an Ubuntu image should be pretty easy to create, but do you know of an example of a NixOS docker image? I've honestly never even run NixOS :P
With a little re-organization an Ubuntu image should be pretty easy to create, but do you know of an example of a NixOS docker image? I've honestly never even run NixOS :P
I did something like that in the past (nix-shell would all necessary dependencies specified in default.nix into /nix/store) but these days, I think I would just go with installing Nix through GitHub Actions and then running something like nix-shell -I nixpkgs=channel:nixos-unstable -E 'let pkgs = import <nixpkgs> { }; in pkgs.mkShell { buildInputs = [ pkgs.gnome.gnome-shell ]; inputsFrom = [ pkgs.gnomeExtensions.gsconnect ]; }' --run 'meson _build' (default.nix pasted inline for simplicity).
Can try to open a PR when I am less busy next week.
Sorry, I have not gotten around to it last time and now I am too busy again.
nixos/nix is the official one, see https://nixos.org/download.html#nix-install-docker.
The ones under nixpkgs/ are built by Nix communitty https://github.com/nix-community/docker-nixpkgs and are useful if you want to have some other tools, e.g. curl baked into the image.