Fate of Travis-CI Nix language support

Development
2

The current state

Summarizing what I’ve seen (I can add citations if anyone disputes these, but if we’re in agreement it’ll be a waste of time):

  1. I’ve only gone through it once, but the “process” of getting changes merged into travis-ci/travis-build and properly tested is tedious and clunky. It’s roughly impossible to iterate quickly without setting up some other solution (whether CI or local) for validating changes.
  2. It doesn’t seem like we have anyone with the right combination of time, interest, and Nix-ecosystem knowledge to keep the build script maintained as-is. (Not casting any shade, here–after dealing with this once I definitely don’t have the time/energy/interest/knowledge to do it either.)
    • No one listed as a maintainer of the integration has opened a PR since Graham’s update to 2.0.4 in August 2018.
    • CI builds against 2.0.4 started breaking over SRI hashes turning up in Nixpkgs. This turned into a complete break for anyone who wasn’t specifying a Nix version when Nixpkgs was updated to a minimum version of 2.2.x.
    • Starting in October 2019, 3 other community members (@curiousleo, @Mic92, and @asymmetric) opened PRs to attempt to bump support up to a 2.3.x release. One of these was promptly reverted because it broke macOS builds, one was open for a little over a month before it was closed over the same issue, and one was finally merged this month after stalling out for 6 months over the same issue.
    • The change finally merged a week ago to fix macOS builds has installs working on both macOS and Linux again, but it has broken Cachix support.
  3. Comments I’ve seen from people in-the-know have unanimously recommending abandoning Travis-CI for GitHub Actions.

Why it’s a problem

I’ll reiterate: no blame; I sympathize with what I perceive as the reasons it is neglected. But:

  • The neglect is leading to complete and partial breaks.
  • Unexpected CI breaks can leave devs/maintainers over a barrel when they just need to get a bugfix out.
  • Repeatedly putting devs in this position is a recurring community/developer-relations/marketing problem, especially given the value proposition for using Nix in CI in the first place.
  • Some of the devs using Nix for CI aren’t terribly Nix savvy or “plugged in”, and may not have even personally built the Nix support in their projects, leaving them poorly equipped to troubleshoot it.
3 Likes