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):
Make a decision to deprecate and eventually end community support on a version or time-based schedule.
Find maintainers who have the time, energy, interest, and Nix-ecosystem knowledge to maintain the support at an acceptable level of quality.
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):
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.
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.
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.
It’s simple, straightforward, cleanly integrated with cachix, free, enabled by default on GitHub without need of a second proprietary account and service …
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 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).
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.
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:
We pick a date or version to end support by. I’m using “October 1” for illustration without much thought.
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
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
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.
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.
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…
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: Nix community projects · GitHub and give some people access to it.
I only set out to create an installer wrapper that people could curl–but I was pretty pleased to discover that Travis CI has added a beta feature at some point that supports importing configs from elsewhere. The result is surprisingly competitive with language: nix:
If you still have projects with a .travis.yml (even if you had toggled off the integration), it would be nice to get a broader test/validation of whether it works. (@utdemir? @mic92?)
Transfer nix-travis-ci somewhere more official like nix-community or nixos. Mic92
Someone currently/recently listed as a maintainer (@garbas@grahamc@matthewbauer@domenkozar) for the integration, by email or by issue, needs to give Travis CI a heads-up that:
we don’t have enough active maintainers to maintain the language support at high quality
we’d like to update the integration with a deprecation notice, removal schedule, and instructions for how projects can update their .travis.yml configs. (not sure they’ve done this before…)
Prep an update to the Ruby builder (can probably sketch it out now, but #3 inevitably shapes the specifics; it probably does things like):
replace the existing maintenance/support message with a prominent warning about the deprecation along with instructions for how to update
after a specific date, the warning is upgraded to a hard build error that must be dismissed by setting an explicit env (i.e., I_ACKNOWLEDGE_NIX_LANGUAGE_SUPPORT_ENDS_MON_DAY)
after the hard date, I’m guessing we’d update the builder to just fail with the error and migration message.
Mic92