Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add Nix CI? #11

Open
ferdnyc opened this issue Jun 6, 2022 · 6 comments
Open

Add Nix CI? #11

ferdnyc opened this issue Jun 6, 2022 · 6 comments

Comments

@ferdnyc
Copy link
Member

ferdnyc commented Jun 6, 2022

Continuing/relocating the in-progress discussion from GSConnect/gnome-shell-extension-gsconnect#1370.
@ferdnyc ferdnyc mentioned this issue Jun 6, 2022
Merged
@andyholmes
Copy link
Collaborator

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.

@ferdnyc
Copy link
Member Author

ferdnyc commented Jun 12, 2022 •
edited
Loading

@andyholmes

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.)

@andyholmes
Copy link
Collaborator

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

@jtojnar
Copy link

jtojnar commented Jun 12, 2022 •
edited
Loading

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.

@ferdnyc
Copy link
Member Author

ferdnyc commented Oct 11, 2022 via email

@jtojnar
Copy link

jtojnar commented Oct 11, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@ferdnyc @jtojnar @andyholmes