GitHub Actions

[gelisam]

Fixes #236. Probably. GitHub Actions always take several attempts...

[gelisam]

The cabal build succeeds, but the stack build doesn't. I need it to check the lower bounds. It fails with setup: The program 'happy' is required but it could not be found... immediately after building happy, so the problem cannot be solved by first installing happy. According to commercialhaskell/stack#157, stack has been working around this problem since 2015. This test is intentionally using the oldest lts I can, lts-8.0, but that's from 2017, so that's not it. Also, haskell/actions/setup uses the latest version of stack by default, so that's not it either. Maybe this is a different problem with the same symptoms?

[gelisam]

With lts-12.26, happy builds just fine. So if this only happens with lts-8.0, I can probably reproduce this locally?

$ stack --stack-yaml=oldest-supported-lts.yaml install happy
Copied executables to /Users/gelisam/.local/bin:
- happy

Nope, succeeds. What's the difference between my laptop's environment and CI's?

[gelisam]

Maybe this is a different problem with the same symptoms?

A later ticket, commercialhaskell/stack#5253 does mention that the same symptom keep reoccurring over and over again in a multitude of tickets. But that one specifically mentions lts-8, so that's probably the problem I am encountering. Unfortunately for me, that ticket is still open!

While trying to reproduce the problem, however, the comments mention that if another version of happy is already globally installed, it might allow that version of happy to build. So maybe I can first install happy from a later lts?

[gelisam]

Same result.

[gelisam]

Despite the fact that installing happy globally didn't help CI, I decided to test whether that had an impact by removing my globally-installed happy on my laptop, and hurray, I am now able to reproduce the problem locally!

$ un `which happy`
$ stack --resolver=lts-8.0 install happy
[...]
happy> Configuring happy-1.19.5...
happy> build
happy> Building happy-1.19.5...
happy> Preprocessing executable 'happy' for happy-1.19.5...
happy> setup: The program 'happy' is required but it could not be found
[...]

[gelisam]

Locally, installing happy globally fixes the problem. So why isn't it helping in CI? Maybe the PATH doesn't include ~/.local/bin/happy?

$ stack install happy
[...]
Copied executables to /Users/gelisam/.local/bin:
- happy
$ which happy
/Users/gelisam/.local/bin/happy
$ stack --resolver=lts-8.0 install happy
Copying from /Users/gelisam/.stack/snapshots/x86_64-osx/ebebc014837b9212abaf99e1171a8098cd83bb269d832c0da8e4e630b1cc18e8/8.0.2/bin/happy to /Users/gelisam/.local/bin/happy

Copied executables to /Users/gelisam/.local/bin:
- happy

[gelisam]

I'm trying to observe some more information about the build environment in CI, but all I get from e.g. which happy is shell: /bin/bash -e {0}. Ah! it's because which happy doesn't print anything if it can't find anything!

[gelisam]

All right, so happy is indeed in ~/.local/bin, but that folder is not in the PATH.

[gelisam]

Youhoo, it worked!

[gelisam]

PATH="..." cmd is not valid syntax on Windows. Now I'm wondering, has hawk ever worked on Windows?

[gelisam]

Now the macOS build is failing. The logs seem to indicate that all the tests pass successfully and yet the executable exits with a non-zero error code:

Examples: 9  Tried: 9  Errors: 0  Failures: 0
Examples: 13  Tried: 13  Errors: 0  Failures: 0
Examples: 18  Tried: 18  Errors: 0  Failures: 0
Examples: 31  Tried: 31  Errors: 0  Failures: 0
Examples: 29  Tried: 29  Errors: 0  Failures: 0

haskell-awk> Test suite reference failed
Test suite failure for package haskell-awk-1.1.1
    reference:  exited with: ExitFailure (-11)

But when we compare that output to a run which actually succeeds, we see that quite a few tests are missing!

$ stack --stack-yaml=stack.yaml test
haskell-awk> test (suite: reference)

Examples: 9  Tried: 9  Errors: 0  Failures: 0
Examples: 13  Tried: 13  Errors: 0  Failures: 0
Examples: 18  Tried: 18  Errors: 0  Failures: 0
Examples: 31  Tried: 31  Errors: 0  Failures: 0
Examples: 29  Tried: 29  Errors: 0  Failures: 0
Examples: 173  Tried: 173  Errors: 0  Failures: 0
Examples: 213  Tried: 213  Errors: 0  Failures: 0
Examples: 33  Tried: 33  Errors: 0  Failures: 0
Examples: 89  Tried: 89  Errors: 0  Failures: 0
Examples: 133  Tried: 133  Errors: 0  Failures: 0
Examples: 41  Tried: 41  Errors: 0  Failures: 0
Examples: 38  Tried: 38  Errors: 0  Failures: 0
Examples: 2  Tried: 2  Errors: 0  Failures: 0
Examples: 15  Tried: 15  Errors: 0  Failures: 0
Examples: 85  Tried: 85  Errors: 0  Failures: 0

repr'
  can convert tuple values
repr
  can convert boolean values
  can convert char values
  can convert double values
  can convert float values
  can convert int values
  can convert integer values
  can convert maybe values
  can convert unit value
  can convert string values
  can convert tuple values
  can convert list values
  can convert map values
  can convert set values

Finished in 0.0039 seconds
14 examples, 0 failures

Hawk
  evals "1" on input "" equals to "1\n"
  evals "1+1" on input "" equals to "2\n"
  evals "[1]" on input "" equals to "1\n"
  evals "[1,2]" on input "" equals to "1\n2\n"
  evals "(1,2)" on input "" equals to "1\n2\n"
  evals "[[1]]" on input "" equals to "1\n"
  evals "[[1,2]]" on input "" equals to "1 2\n"
  evals "[[1,2],[3,4]]" on input "" equals to "1 2\n3 4\n"
  evals "id" on input "foo" equals to "foo\n"
  evals "L.transpose" on input "1 2\n3 4" equals to "1 3\n2 4\n"
  evals "L.map (!! 1)" on input "1 2\n3 4" equals to "2\n4\n"
  evals "(!! 1)" on input "1 2\n3 4" equals to "2\n4\n"

Finished in 2.1845 seconds
12 examples, 0 failures

haskell-awk> Test suite reference passed

So something happens between the Examples: 29 and Examples: 173 lines. I am guessing that one of those 173 examples fails so hard that it crashes the test suite?

[gelisam]

This time we have a clearer error message, not sure why it was elided before:

Examples: 29  Tried: 29  Errors: 0  Failures: 0
reference: 
lookupSymbol failed in relocateSection (RELOC_GOT)
/Users/runner/.stack/programs/x86_64-osx/ghc-8.4.4/lib/ghc-8.4.4/integer-gmp-1.0.2.0/HSinteger-gmp-1.0.2.0.o: unknown symbol `___gmp_rands'
reference: reference: unable to load package `integer-gmp-1.0.2.0'

I've actually encountered this locally earlier, and the solution I found online is simply to delete this .o file.

[gelisam]

/Users/runner/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.4: /Users/runner/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.4: cannot execute binary file

Huh? but the build step worked just fine a moment ago, it was the test step which was failing, the build step was working fine! What's going on?

[gelisam]

/Users/runner/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.4: data

looks like the file is not recognized as a macOS executable. Maybe it got corrupted somehow?

[gelisam]

skipping the cache worked, so I guess it did get corrupted. but I do want a cache, so that builds don't take so long. what if I simply create a new cache?

[gelisam]

seems to work! I don't know how the cache got corrupted in the first place, I just hope it doesn't happen again.

[gelisam]

>>> ancestors "/bin"'

expected: ["/","/bin"]
but got: ["","/","/bin"]

Okay, those hardcoded / paths tell me that those tests have never been run on Windows before, so I shouldn't expect them to pass now. I'll disable the Windows build and then re-enable them in #239 .

[gelisam]

Finally!