zef install fails when building a Dockerfile in Travis

[JJ]

Check out this https://travis-ci.org/JJ/alpine-perl6/builds/310471878
It also fails, same error, in Docker hub

Context

Building locally this Dockerfile https://github.com/JJ/alpine-perl6/ works without a problem. However, it fails in Travis and Docker Hub.

Expected Behavior

I would expect it to work exactly the same way, since Dockerfile descriptions are unambiguous. It might have to do with the Docker cache, but I would expect it to fail locally, not in the cloud.

Actual Behavior

Error as above https://travis-ci.org/JJ/alpine-perl6/builds/310471878
And here too: https://hub.docker.com/r/jjmerelo/alpine-perl6/builds/bpuk3prltfj87pxv2ksyrp3/

Steps to Reproduce

Fork and download the repo, configure it for a Travis build, and push it

Your Environment

I'm using rakudobrew build moar, and rakudobrew build zef after that in an Alpine container as above.

[ugexe]

The t/ tests don't make any network requests, and in fact all the real testing happens in xt/ (which isn't run by rakudobrew/zef). So the test failure is probably in https://github.com/ugexe/zef/blob/master/t/utils-filesystem.t which make me think it is either something like $HOME or $TMPDIR not being set in the environment (although if I understand correctly this shouldn't be the case with this Dockerfile? maybe the cloud provider sets/changes one of these?)

[JJ]

It's run inside a container, and it should be the self-same one locally and anywhere else. Only think I can think of is the underlying filesystem where everything is running, which should be different. But I don't know how this might affect the build. I also had a similar error in another one, File::Which (if I remember correctly). But I need to know what is precisely the problem what is the matter with the filesystem.

[JJ]

The only difference I have found is the one mentioned here: https://forums.docker.com/t/what-is-dirperm1-supported/2550/2 Locally, dirperm1 is false (and kernel 3.13) and Travis uses dirperm1 true (and kernel 4.4). However, it should have been the other way round, something not working locally and working in Travis, right?

[ugexe]

To get the precise test failure, run the following after installing rakudo:
git clone https://github.com/ugexe/zef.git && prove -v -e 'perl6 -I zef/lib' zef/t

It's also probably a good idea to add the -v flag to rakudobrew's invocation of zef test.

[JJ]

OK, I'll do that. Meanwhile, my hunch is that it's related to an AUFS bug related to permissions https://github.com/sfjro/aufs3-linux/tree/aufs3.18/Documentation/filesystems/aufs
That is obviously not your fault, but I wonder if I could find a workaround in that case...

[JJ]

There does not seem to be a problem with the test phase, but with the installation phase itself. I'm running it with verbose to see what's going on https://travis-ci.org/JJ/alpine-perl6/builds/310572021

[ugexe]

You need to call zef/bin/zef install ... (and -I zef/lib) as the last command unless you first cd zef

[JJ]

Yep, I've added that now. Thanks anyway.

[ugexe]

perl6 -I zef/lib zef/bin/zef --verbose install zef/

[JJ]

It's working now https://travis-ci.org/JJ/alpine-perl6
I don't know what did the trick, but it worked :-) Thanks!

[ugexe]

I suspect installing prove fixed it. To emulate the previous state locally you would do perl6 -Ilib bin/zef --/prove install . which disables prove and falls back to running the test files 1 by 1 via perl6 -I $some-lib $test-file. These 2 variants shouldn't result in differences in exitcode, but when it does (because it has before) its usually something in Test.pm

[JJ]

But would that differences in exit code account for the error in installation?

[ugexe]

If you are referring to rakudobrew then it does zef test . before installing, and never reached the zef install . command. The tests failed, but we never saw the output with zef -v ... before prove was installed (I suspect the output would say everything is OK, but the exitcode was non-zero for an unknown reason).

[JJ]

Not sure about that... Since the other thing that has changed is the path, could that be it? We're running it now from the top directory.

[JJ]

And the other thing is the openssl-dev package. If zef depends on that, it might fail for that reason... Bringing me back to my #215 issue: more information is needed on failure. We really don't know why it failed before...

[ugexe]

Perhaps... maybe that + precomp end up with it trying to write somewhere it shouldn't. You might try to cd zef after cloning it and trying it from inside to emulate how rakudobrew does it.

[ugexe]

zef doesn't depend on openssl-dev

[JJ]

It's building up nicely now... https://travis-ci.org/JJ/alpine-perl6/builds/310587658

[JJ]

@ugexe beats me, then... It must be the .precomp thing, combined with the difference in storage driver locally and in Travis or Docker hub. Thanks for all your help, much appreciated!