skip hog tests in build environments where hog is not built or not available

[kthielen]

Thanks to @thmzlt, I think that this should unblock our test run during nix builds (so we can make hobbes available on nixOS).

[thmzlt]

I noticed the nixpkgs tarball in default.nix is set to track the latest version of the unstable branch, and gcc5 is no longer available there. We should either pin the nixpkgs version to a commit or use a lower/higher version of gcc:

[kthielen]

It makes sense to pin the nixpkgs version at least to make the change history make more sense (so when upgrading a gcc compiler version it'd be in a PR for that purpose).

Ultimately we will probably want to update gcc too. I'm not sure what most people are using, we're probably a little behind the times.

Do you know if there's a way I can try the nixOS build process on this PR? Since the tests make some references to local files, and the nixOS build process seems to play some funny games with build directories, I might need to iterate on this PR a few times to shake out those issues.

Alternately, I guess we could disable tests for the nixOS build since we already do them here, but that probably doesn't look kosher.

[thmzlt]

I was just able to build hobbes with the following default.nix:

{ pkgs ? import (fetchTarball https://github.com/nixos/nixpkgs-channels/archive/cc1ae9f21b9e0ce998e706a3de1bad0b5259f22d.tar.gz) {} }:

pkgs.stdenv.mkDerivation {
  name = "hobbes";
  src = ./.;

  nativeBuildInputs = with pkgs; [
    ccls
    cmake
    gcc8
    llvm_6
    ncurses
    python27
    readline
    zlib
  ];

  doCheck = false;
  checkTarget = "test";
}

The commit is what nixpkgs-unstable was pointing to at the time. LLVM 6 and GCC 8.3 are the highest versions that worked (LLVM 7 and GCC 9 break the build). I set doCheck to false in order to complete the build without running tests.

Do you know if there's a way I can try the nixOS build process on this PR?

Do you mean locally? I'm using nix-build at the project root.

[thmzlt]

Looks like now the non-nix build is getting stuck running tests.

[kthielen]

Yeah, it looks very strange considering that this PR now has no code changes (so is the same as all of the builds that have tested fine for months). I think it's probably an issue on the CI host, will have to dig further tonight.

[kthielen]

I started another PR just to test it: https://github.com/Morgan-Stanley/hobbes/pull/331

It looks like we're not getting an inotify signal for a file update that we expect (and which was always delivered before). It might be interesting. :)

[thmzlt]

Can you trigger a new build of this PR (via the Travis UI)?

[kthielen]

Yeah, it looks like something has changed on the ci Linux hosts, very strange, at least it's repeatable between restarts. I will work on getting to the bottom of it this weekend. This is the first time that this has happened. :T

[kthielen]

It looks like something like this (https://william-yeh.net/post/2019/06/inotify-in-containers/) has started making the inotify-based tests unreliable. I've temporarily disabled them to get these two pull requests passing (nothing in either PR changes the inotify logic in any way). I have a separate conversation going out of band with folks at travis-ci to sort out what changed.

Hopefully this will be enough to resume progress on the nixOS PR as well.

[kthielen]

Already merged through vtrunc, which was a superset of this PR.