Fate of Travis-CI Nix language support

I’m hoping to draw out an explicit/decisive discussion about what seems to have slowly become the de facto state of the Nix language support for Travis-CI: neglect.

For this first post, I’ve assumed there’s general agreement to avoid burying the solution under the justification. If you don’t agree with my assertion, or that it’s a problem, see the 2nd post for more.

How to address it

One of two things should probably happen (soon–while the current support roughly works):

  1. Make a decision to deprecate and eventually end community support on a version or time-based schedule.
  2. Find maintainers who have the time, energy, interest, and Nix-ecosystem knowledge to maintain the support at an acceptable level of quality.

Mentioning people who’ve touched the CI (that aren’t already mentioned in post 2): @grahamc @garbas @domenkozar @matthewbauer

4 Likes

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

I personally have migrated all my projects to github actions except NUR, where the migration would take a bit more time because I also need to migrate: https://github.com/nix-community/nur-update

2 Likes

Is there any reason to continue using Travis at all, now that GitHub actions is here? I’ve also migrated everything and found it strictly superior.

It’s simple, straightforward, cleanly integrated with cachix, free, enabled by default on GitHub without need of a second proprietary account and service …

3 Likes

I don’t really see one, and it definitely seems like the consensus, so I have already started the process of migrating my own projects off as well.

I lean heavily toward option 1, but in any case my primary concern is just that it either be well-terminated, or well-maintained :slight_smile:

Since I wrote GitHub Actions for Nix, I loudly advocated that it’s superior in any sense:

  • it has reusable components
  • it’s way more performant (some of my projects built twice faster)
  • it doesn’t have the annoying 60min timeout on travis (you can configure it up to 10h)
  • configuration is more thought through (since it’s next generation)
  • setting up Nix + Cachix is really a breeze
  • Travis was sold by the original founders just before GitHub Actions were launched and many of the original team has since left the company, which gives some room for speculation where the innovation is going to be

I did notice one good reason to use travis, that’s aarch64 support: https://blog.travis-ci.com/2019-10-07-multi-cpu-architecture-support that I’ve added to patchelf: https://github.com/NixOS/patchelf/commit/1e1867de901651a317244e406c057383952dd509

I do believe that given so much of industry is moving to arm, it’s just a matter of time before GitHub supports it as well (if nothing else, due to mac needing arm).

5 Likes

I also like GitHub actions, but to me the major downside is the disk space limit. On GitHub actions executor, there is less than 10 gigabytes of disk space available, and that might not be enough for larger Nix projects. This is already prohibitive for two of my projects.

Travis is better in this regard, by providing about 50 gigabytes of disk space.

1 Like

It has 14GB free on SSD, but you can reclaim up to 100GB more with:

- run: sudo rm -rf /opt /usr/local || true
12 Likes

@utdemir Do you think (or can you try?) reclaiming space as Domen suggests satisfies this concern?

Is travis-ci nix support a must for gitlab users? I know gitlab has some ci stuff but no idea about nix support.

Edit: my bad. I forgot that travis-ci is probably just for GitHub

I had this thought, too. As far as I can tell it looks like it’s just github.

1 Like

Since the only technical objection so far has a workaround and no one’s clamoring for maintainership, it seems like intentional deprecation and eventual removal is still the obvious path forward.

I imagine something like:

  1. We pick a date or version to end support by. I’m using “October 1” for illustration without much thought.

  2. Develop & host a resource somewhere (distinct page? github issue? discourse thread? Wiki page? Gist? New repo?) that explains:

    • why support is ending
    • how to transition your project to github actions
  3. PR an update to the Nix builder for travis-ci to:

    • Error out before installing Nix unless a new environment variable is present. Give this variable a name like ACKNOWLEDGE_NIX_LANGUAGE_SUPPORT_ENDS_OCT_1
    • Add a deprecation warning message (printed with the error above and in the “Nix support for Travis CI is community maintained…” announcement) that:
      • explains we’re ending support on or after October 1, 2020
      • points to a URL with more on how they should update their projects
  4. Prepare doc/build PRs to implement the eventual removal and open them as drafts so that we can spend a little time working with someone at travis-ci on what the final step should look like. I couldn’t find clear evidence that someone’s ended community support for a language yet, nor do I see any documented process for doing it, so it may take them a bit to decide. I assume they’ll want to leave stubs behind to throw removal notices and such.

  5. Optional/optimistic: If we can find a good way to build a prioritized list of active projects that are using travis-ci with Nix (and find a few people on our end with a little spare energy…) I think it would be a nice gesture to PR working Github Actions configs that ~match their travis-ci configs.

If the PR or deprecation efforts create enough noise to make it obvious there’s still demand specific to travis-ci (but fails to locate 3 maintainers–the minimum travis-ci cites for a community-supported language), it may make sense to continue with deprecation/removal but also host a repo with an install script and instructions on how users can add it to their .travis.yml for less-official support. I’m not a fan of this, but I think it would at least be less tedious to iterate on.

2 Likes

Another feature travis supports but not github is nested virtualisation, which is for example interesting for nixos tests.

1 Like

Are you doing this, or aware of someone who is?

Assuming we know of projects that are, I see this as a point for maintaining a separate repo with an install script that can still be used to install Nix on travis-ci, but not necessarily as a point against sunsetting the language integration (unless the people doing this are themselves highly-motivated to maintain the integration?)

What if we maintain a repo that just has a travis.yml template that contains the nix installer? Than people can make PRs and test the script itself and we don’t have to wait for travis upstream. I mean in the end the travis integration does not do much and I think it will make fixes go through faster. It’s just that other project than have to pull the template manually…

It seems like a good middle path.

I (naively) suspect it would be easier to maintain, especially if it can be cut down to a fairly thin wrapper around the installer with fewer things that can break, with a clear feedback loop from tests that exercise all of the main configurations.

Do you know much about how people bootstrap Nix on other CIs (Jenkins, Circle, GitLab?) I wonder a little if there’s a core of pan-CI functionality (beyond the installers themselves) that is feasible to abstract out in a way that general CI-related chores get done once globally, but I guess they may all have enough quirks that this isn’t feasible.

I would say the installer is the common core part already. The rest is glue code specific to the CI.
I suggest creating a travis template in: github.com/nix-community and give some people access to it.