Nixpkgs: Get Nix to be a supported language on travis-ci

[domenkozar]

We need 3 people to be official supported for community-supported Nix at travis-ci. This way we could use their docker container infrastructure, which is way superior of the old VM based. I'm volunteering to be one of the 3.

After we have 2 more Nix developers, we have to go through https://docs.travis-ci.com/user/languages/community-supported-languages/ to get it upstream.

Current situation

If one wants to be able to use nix in a project, you have to use sudo to install Nix first. For example:
https://github.com/domenkozar/hydra-frontend/blob/master/.travis.yml

After Nix being first-class citizen in travis-ci

The .travis.yml file would be:

language: nix
script: ./bin/runtests

That's it. Nix integration would provide an image with installed package manager and run nix-build in install phase.

cc @copumpkin for updated before/after section

[garbas]

count me in

[matthewbauer]

I can help on this. Has anyone tried to make a module for "travis-build"?

The files look like this from c.rb:

module Travis
  module Build
    class Script
      class C < Script
        DEFAULTS = {
          compiler: 'gcc'
        }
        LLVM_APT_REPO_MSG = "The LLVM APT rpository is currently available. " \
          "Your builds may fail if your build updates LLVM/clang to a newer version with 'apt'. " \
          "Please see https://github.com/travis-ci/travis-ci/issues/6120#issuecomment-224072540 for a workaround."

        def export
          super
          sh.export 'CC', compiler
          if data.cache?(:ccache)
            sh.export 'PATH', "/usr/lib/ccache:$PATH"
          end
        end

        def announce
          super
          if compiler.include? 'clang'
            sh.echo LLVM_APT_REPO_MSG, ansi: :yellow
          end
          sh.cmd "#{compiler} --version"
        end

        def script
          sh.cmd './configure && make && make test'
        end

        def cache_slug
          super << '--compiler-' << compiler
        end

        def setup_cache
          if data.cache?(:ccache)
            sh.fold 'cache.ccache' do
              sh.echo ''
              directory_cache.add('~/.ccache')
            end
          end
        end

        def use_directory_cache?
          super || data.cache?(:ccache)
        end

        private

          def compiler
            config[:compiler].to_s
          end
      end
    end
  end
end

My thinking is we can put what's in our "travis-nox-review-pr.sh nix" stage into "configure", "travis-nox-review-pr.sh nox" into "install", and then have travis options to specify a derivation to build. This should make it versatile enough so projects outside of "nixpkgs" will just have to specify a derivation.

[garbas]

@matthewbauer awesome work! what is the current status and where can the rest of us help you finish this?

[matthewbauer]

Would there be any reason to have build matrices for Nix? I don't think we have any need to have different version of Nix Could someone verify that the script works? We need to ping a Travis dev to let us test it on real Travis builders still.

I'm thinking of rewriting the /install part to use a customized install method that skips over some of the unnecessary stuff from "install-nix-from-closure.sh". I also haven't figured out the proper way to implement caching. Ideally we'd want the Nix binaries to be cached and perhaps some other commonly used binary caches.

@domenkozar Is there a reason the travis script has to build NixOS/nixpkgs tarballs each time? https://github.com/NixOS/nixpkgs/blob/master/maintainers/scripts/travis-nox-review-pr.sh#L34-38

[domenkozar]

Would there be any reason to have build matrices for Nix? I don't think we have any need to have different version of Nix Could someone verify that the script works? We need to ping a Travis dev to let us test it on real Travis builders still.

I don't think this is necessary. We/Whoever can implement that if need arises

I'm thinking of rewriting the /install part to use a customized install method that skips over some of the unnecessary stuff from "install-nix-from-closure.sh". I also haven't figured out the proper way to implement caching. Ideally we'd want the Nix binaries to be cached and perhaps some other commonly used binary caches.

Skip what unnecessary stuff? And what do we gain by skipping it?

@domenkozar Is there a reason the travis script has to build NixOS/nixpkgs tarballs each time? https://github.com/NixOS/nixpkgs/blob/master/maintainers/scripts/travis-nox-review-pr.sh#L34-38

Those two checks evaluate all packages and NixOS module to be sure evaluation still works.

[matthewbauer]

Mainly skipping this part: https://github.com/NixOS/nix/blob/master/scripts/install-nix-from-closure.sh#L92-128. It mainly just pollutes the logs with something that isn't very useful for one-time installs.

So, I'm thinking that the NixOS evaluation thing should be left in there. So nixpkgs .travis.yml will eventually look something more like:

# .travis.yml
language: nix
matrix:
  include:
    - env: TASK="verify tarball"
      os: osx
    - env: TASK=pr
      os: osx
    - env: TASK="verify tarball options"
      os: linux
    - env: TASK=pr
      os: linux
      sudo: required
      dist: trusty
cache:
  directories:
    - /nix/
script: ./maintainers/scripts/travis-nox-review-pr.sh $TASK

#!/usr/bin/env sh
# ./maintainers/scripts/travis-nox-review-pr.sh

set -ev

while test -n "$1"; do
  case "$1" in
    verify)
      echo "=== Verifying that nixpkgs evaluates..."
      nix-env -f. -qa --json
      shift
    ;;
    options)
      echo "=== Checking NixOS options"
      nix-build nixos/release.nix -A options --show-trace
      shift
    ;;
    tarball)
      echo "=== Checking tarball creation"
      nix-build pkgs/top-level/release.nix -A tarball --show-trace
      shift
    ;;
    lint)
      # TODO
    ;;
    pr)
      if [[ $TRAVIS_PULL_REQUEST == false ]]; then
        echo "=== Not a pull request"
      else
        echo "=== Checking PR"
        nix-shell -p nox --run "nox-review pr $TRAVIS_PULL_REQUEST"
      fi
      shift
    ;;
    *)
      shift
    ;;
  esac
done

This will use the "container-based" Travis worker which may cause some unplanned issues: https://docs.travis-ci.com/user/ci-environment/#Virtualization-environments vs Trusty. Specifically, boots should be faster but there will also be less memory available. I'm thinking if we can get caching to work properly, we won't run into as many "out of space" issues.

[domenkozar]

4GB will cause issues, for nixpkgs.git we should still use Trusty beta.

[matthewbauer]

I updated the above post to use Trusty for building, but IMO it may be useful to separate "pr" building and "package set" building. This would increase the number of Travis instances from 2 to 4 but it can hopefully make some of the "out of space" and "timeout" errors disappear.

[datakurre]

@matthewbauer @domenkozar Even if this would not help nixpkgs PRs, this would help using nixpkgs for building and testing other projects. What are the missing parts from getting this forward? Not being able to use Nix on Travis without sudo makes it currently inconvenient to use Nix in projects outside Nixpkgs (because a duplicate non-Nix build chain must be provided for Travis).

[moretea]

@datakurre I'm just running a script that does a nix-build on a travis machine with sudo set to true. See moretea/rust-zfs. Works fine for me :) What non-nix build chain are you referring to?

[matthewbauer]

@moretea The "container-based" Travis environment are a little bit faster and tend to have less of a backlog and sudo isn't available for those. https://docs.travis-ci.com/user/ci-environment/#Virtualization-environments

[domenkozar]

This is now upstream, many thanks to @matthewbauer - who has done all the work.

See https://docs.travis-ci.com/user/languages/nix