Commits on Source (15)
-
Ben disabled them in cd85f8a7 but didn't say how or why they were broken.
-
-
-
Ben Gamari authored
GitLab creates a shallow clone. However, this means that we may not have the base commit of an MR when linting, causing `git merge-base` to fail. Fix this by passing `--unshallow` to `git fetch`, ensuring that we have the entire history.
-
Ben Gamari authored
The job script didn't even try to compute the base commit to lint with respect to.
-
Ben Gamari authored
-
[skip ci] This should really be caught by the linters! (#16711)
-
Ben Gamari authored
Previously we were passing `--unshallow` to `git fetch` in the linting rules to ensure that the base commit which we were linting with respect to was available. However, this breaks due to GitLab's re-use of working directories since `git fetch --unshallow` fails on a repository which is not currently shallow. Given that `git fetch --unshallow` circumvents the efficiencies provided by shallow clones anyways, let's just disable them entirely. There is no documented way to do disable shallow clones but on checking the GitLab implementation it seems that setting `GIT_DEPTH=0` should do the trick.
-
Ben Gamari authored
There is no notion of a base commit when we aren't checking a merge request. Just check the HEAD commit.
-
Ben Gamari authored
The previous commit reworked things such that the submodule linter would only run on the head commit. However, the linter only checks the submodules which are touched by the commits it is asked to lint. Consequently it would be possible for a bad submodule to sneak through. Thankfully, we can use the handy CI_COMMIT_BEFORE_SHA attribute to find the base commit of the push.
-
Ben Gamari authored
This was previously failling on Windows.
-
Ben Gamari authored
On Windows we must lock package databases even when opening for read-only access. This means that concurrent GHC sessions are very likely to fail with file lock contention. See #16773.
-
Ben Gamari authored
This test uses TemplateHaskell causing GHC to build dynamic objects on platforms where dynamic linking is available. However, Windows doesn't support dynamic linking. Consequently the test would fail on Windows with: ```patch --- safeHaskell/safeInfered/UnsafeInfered02.run/UnsafeInfered02.stderr.normalised 2019-06-04 15:10:10.521594200 +0000 +++ safeHaskell/safeInfered/UnsafeInfered02.run/UnsafeInfered02.comp.stderr.normalised 2019-06-04 15:10:10.523546200 +0000 @@ -1,5 +1,5 @@ -[1 of 2] Compiling UnsafeInfered02_A ( UnsafeInfered02_A.hs, UnsafeInfered02_A.o, UnsafeInfered02_A.dyn_o ) -[2 of 2] Compiling UnsafeInfered02 ( UnsafeInfered02.hs, UnsafeInfered02.o, UnsafeInfered02.dyn_o ) +[1 of 2] Compiling UnsafeInfered02_A ( UnsafeInfered02_A.hs, UnsafeInfered02_A.o ) +[2 of 2] Compiling UnsafeInfered02 ( UnsafeInfered02.hs, UnsafeInfered02.o ) UnsafeInfered02.hs:4:1: UnsafeInfered02_A: Can't be safely imported! ``` The other approach I considered for this issue is to pass `-v0` to GHC. However, I felt we should probably do this consistently for all of the tests in this directory and this would take more time than I currently have. -
Ben Gamari authored
While linking is still slow (#16084) all of the correctness issues which were preventing us from being able to enforce testsuite-green on Windows are now resolved.
-
Ben Gamari authored
Strangely the path it emits contains duplicate path delimiters (#16772), ```patch --- ghc-api/downsweep/OldModLocation.run/OldModLocation.stderr.normalised 2019-06-04 14:40:26.326075000 +0000 +++ ghc-api/downsweep/OldModLocation.run/OldModLocation.run.stderr.normalised 2019-06-04 14:40:26.328029200 +0000 @@ -1 +1 @@ -[Just "A.hs",Just "mydir/B.hs"] +[Just "A.hs",Just "mydir//B.hs"] ```