nix-community / lorri

Your project’s nix-env [maintainer=@Profpatsch,@nyarly]
Apache License 2.0
639 stars 24 forks source link

CI: update nixpkgs, add workflow dispatch #87

Closed nyarly closed 1 year ago

nyarly commented 2 years ago

For debugging CI failures.

Updated Nixpkgs pin, and added workflow_dispatch

symphorien commented 2 years ago

maybe keeping CI on 20.09 is too ambitious. Current stable looks good enough in my opinion.

nyarly commented 2 years ago

@symphorien What I'm finding is that anything older than current stable isn't going to work with Cargo 1.60 - dep: features wind up producing a bash variable like RUST_FEATURE_DEP:THING and then bash fails. There's a commit to nixpkgs that suppresses these variables, which seems to be the right solution, but it's only in 22.09.

The remaining issue (@Profpatsch ?) is that the MacOS build is still pulling in attr because of libpcap which seems to be part of Clippy and run-without-network. I'm going to try to dig in and figure out where the issue is there, but I saw a comment about libpcap getting pulled in and was wondering if there were hints about that?

Probably we could restrict the Mac build to just do the Rust tests, since code formatting etc aren't platform-level concerns.

symphorien commented 2 years ago

There's a commit to nixpkgs that suppresses these variables, which seems to be the right solution, but it's only in 22.09.

maybe it makes sense to backport it to 22.05, since 22.05 has rust 1.60

nyarly commented 2 years ago

Correction: 22.05 has the fix, but that's the earliest. I think the upshot it that we can't expect Lorri to build previous to that, since there's dep: features used in its configuration.

symphorien commented 2 years ago

Any specific reason that we should support older than supported nixos releases? Especially if it's difficult to do it... Besides, nix makes it reasonably easy to install lorri from latest nixos on older nixos releases anyway.

nyarly commented 1 year ago

The current state is is that macOS fails the unit tests in a mysterious way:

# fatal runtime error: failed to initiate panic, error 5
#      Running unittests (target/debug/deps/lorri-9519bc6214935066)
...
# Caused by:
655
#   process didn't exit successfully: `/Users/runner/work/lorri/lorri/target/debug/deps/lorri-f086cde207eb53b5` (signal: 6, SIGABRT: process abort signal)

This happens when running the full CI suite, or all the unit tests (either with cargo test --lib or cargo test -- ... with all the unit tests named. Running unit tests individually or in groups of half the set both pass.

The bisected run is especially confusing; the suite failing, but individual tests passing leads me to the hypothesis that there's a pair of tests that are somehow interacting. But the bisection runs all 6 pairs of two quarters of the suite (c.f. nix/ci/default.nix), so every pair should be running together there.

I'm starting to be inclined to configure a Mac test run that runs everything but unit tests, and then runs the units individually, shameful that that solution would be.

Profpatsch commented 1 year ago

I like it! A shame that macOS requires so many workarounds, but it’s to be expected I guess.

I looked through the diff, and everything looks pretty good, plus CI is green again, so LGTM