You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Multiple [GHC](http://haskell.org/ghc) Versions for [Travis-CI](https://travis-ci.org)[](https://travis-ci.org/haskell-CI/haskell-ci)
The purpose of this document is to describe how to set up the [`.travis.yml` script](http://about.travis-ci.org/docs/user/build-configuration/) in order to build and test your [cabalized](http://www.haskell.org/cabal) Haskell package with multiple [GHC](http://haskell.org/ghc) configurations.
5
-
At time of writing [Travis-CI](https://travis-ci.org/) has [support for building Haskell packages](http://about.travis-ci.org/docs/user/languages/haskell/) but only for a single GHC configuration (i.e. *Haskell Platform 2012.2.0.0 with GHC 7.4.1*). By following this guide, you can set up [Travis-CI](https://travis-ci.org/) jobs which have access to the following GHC versions (all compiled for *Ubuntu Linux 12.04 LTS 64-bit*):
4
+
At the moment `haskell-ci` support GitHub Actions workflow generation.
5
+
There is also legacy Travis-CIconfiguration generator, which is unmaintained.
`haskell-ci` relies on [`hvr-ppa`](https://launchpad.net/~hvr/+archive/ubuntu/ghc)
8
+
or [`ghcup`](https://www.haskell.org/ghcup/) to install GHC
9
+
and `cabal-install`.
22
10
23
-
Each GHC version is provided in a separate `ghc-<version>``.deb` package installing into `/opt/ghc/<version>` (thus allowing to be installed at the same time if needed) published in a [PPA](https://launchpad.net/~hvr/+archive/ghc). The easiest way to "activate" a particular GHC version is to prepend its `bin`-folder to the `$PATH` environment variable (see example in next section).
24
-
25
-
Note: For actually enabling continuous integration for a GitHub hosted project, see section [Getting Started](http://about.travis-ci.org/docs/user/getting-started/) in [Travis-CI](https://travis-ci.org/)'s online documentation.
11
+
GHC-7.0.1 — GHC-9.2.1 are supported.
26
12
27
13
### Quick-start instructions
28
14
@@ -40,9 +26,6 @@ Note: For actually enabling continuous integration for a GitHub hosted project,
40
26
cabal new-install haskell-ci
41
27
```
42
28
43
-
*Note:* currently (2019-02-12) released version of `haskell-ci` installs
44
-
an executable named `make-travis-yml`
45
-
46
29
* Step 2: Change directories to your project:
47
30
48
31
```bash
@@ -60,53 +43,49 @@ Note: For actually enabling continuous integration for a GitHub hosted project,
60
43
61
44
Add as many or as few GHC versions to test as you want.
62
45
63
-
* Step 4: Generate a Travis file for your project:
46
+
* Step 4: Generate a workflow file for your project:
64
47
65
48
```bash
66
49
$ # You run the following command from your project's directory, even
67
50
$ # though it references the script from the `haskell-ci` project
If you have Travis enabled for your repository this will test your branch
93
-
using your newly created Travis file. This lets you test the Travis script
94
-
before merging the new script into `master`.
95
-
96
75
* Step 6: Fix the build
97
76
98
77
If you're lucky, your repository will build for every compiler version
99
78
you listed. If that's the case, then just merge your changes into `master`:
100
79
101
80
```bash
102
81
$ git checkout master
103
-
$ git merge new_travis# Update `master` with your new Travis script
82
+
$ git merge new-ci# Update `master` with your new CI script
104
83
$ git push
105
84
```
106
85
107
86
You can also merge your branch into `master` from Github's pull request view.
108
87
109
-
If you're not lucky, then your new Travis branch will fail for one or more
88
+
If you're not lucky, then your new CI branch will fail for one or more
110
89
versions of GHC, which is okay! Look at the build and fix any build failures
111
90
you find and commit the fixes to your branch:
112
91
@@ -116,231 +95,9 @@ Note: For actually enabling continuous integration for a GitHub hosted project,
116
95
$ git push # Push your branch updates upstream
117
96
```
118
97
119
-
Sometimes you may need to regenerate Travis script. for example, to
120
-
remove the `cabal check` step (pass `--no-cabal-check` flag to `haskell-ci)
121
-
if you know for sure that you need build your project with the `-O2` flag.
122
-
123
-
Each time you push an update to your branch Travis will run again to see if
124
-
any build failures still remain. Repeat this process until your project
125
-
builds against each GHC version you listed. Once your project builds against
126
-
each target version of GHC you can merge your Travis script into `master`
127
-
128
-
### Add-on Packages
129
-
130
-
For convenience, a few add-on packages are available to provide more recent versions of `cabal`, `alex` and `happy` than are available in Ubuntu 12.04.
131
-
132
-
They install into a respective `/opt/<name>/<version>/bin` folder (see table below) which can be put into the search `$PATH`.
133
-
134
-
There's also a `/opt/ghc/bin` (& `/opt/cabal/bin`) folder which contains version-suffixed symlinks to installed GHC versions for convenient use with `cabal` (e.g. "`cabal new-build -w ghc-7.8.4`"), as well as symlinks managed by [`update-alternatives(1)`](https://manpages.debian.org/unstable/dpkg/update-alternatives.1.en.html) which can be configured via
135
-
136
-
sudo update-alternatives --config opt-ghc
137
-
sudo update-alternatives --config opt-cabal
138
-
139
-
Note that `/opt/ghc/bin` also contains a default symlink for `cabal`, so it's enough to include `/opt/ghc/bin`in your PATH to get access to both `cabal` and `ghc`.
Since 2015, Travis-CI is migrating build-jobs towards a [contained-based infrastructure](http://docs.travis-ci.com/user/workers/container-based-infrastructure/) which requires a different way to setup the build-matrix in the first half of the `.travis.yml`.
166
-
167
-
The following `.travis.yml` snippet shows the different `matrix` and
168
-
`before_install` sections (relative to the non-container
The top-level `tested-with:` field has a similiar syntax to the `build-depends:` field but with compilers instead of packages. The script contains a list of known GHC versions and emits entries for all matching versions. Here are a few examples:
198
-
199
-
```
200
-
tested-with: GHC >= 7.4 &&< 7.8
201
-
-- selects GHC 7.4.1, 7.4.2, 7.6.1, 7.6.2, and 7.6.3
If you need additional Ubuntu packages installed (e.g. `alex-3.1.5` or `libxml-dev`), you can pass the Ubuntu package names as additional commandline arguments after the `.cabal` filename argument.
208
-
209
-
### Known Issues
210
-
211
-
- The container environment reports 16 cores, causing `cabal`'s default configuration (`jobs: $ncpus`) to run into the [GHC #9221](https://ghc.haskell.org/trac/ghc/ticket/9221) bug which can result in longer build-times. This can be workarounded by commenting out the `jobs: $ncpus` right after `cabal update` creates that file:
212
-
213
-
```yaml
214
-
install:
215
-
# ...
216
-
- travis_retry cabal update
217
-
- sed -i 's/^jobs:/-- jobs:/' ${HOME}/.cabal/config
Below is a commented `.travis.yml` example that can be used as a template:
226
-
227
-
```yaml
228
-
# NB: don't set`language: haskell` here
229
-
230
-
# explicitly request legacy non-sudo based build environment
231
-
sudo: required
232
-
233
-
# The following enables several GHC versions to be tested; often it's enough to test only against the last release in a major GHC version. Feel free to omit lines listings versions you don't need/want testing for.
234
-
env:
235
-
- CABALVER=1.16 GHCVER=6.12.3
236
-
- CABALVER=1.16 GHCVER=7.0.1
237
-
- CABALVER=1.16 GHCVER=7.0.2
238
-
- CABALVER=1.16 GHCVER=7.0.3
239
-
- CABALVER=1.16 GHCVER=7.0.4
240
-
- CABALVER=1.16 GHCVER=7.2.1
241
-
- CABALVER=1.16 GHCVER=7.2.2
242
-
- CABALVER=1.16 GHCVER=7.4.1
243
-
- CABALVER=1.16 GHCVER=7.4.2
244
-
- CABALVER=1.16 GHCVER=7.6.1
245
-
- CABALVER=1.16 GHCVER=7.6.2
246
-
- CABALVER=1.18 GHCVER=7.6.3
247
-
- CABALVER=1.18 GHCVER=7.8.1 # see note about Alex/Happy for GHC >= 7.8
248
-
- CABALVER=1.18 GHCVER=7.8.2
249
-
- CABALVER=1.18 GHCVER=7.8.3
250
-
- CABALVER=1.18 GHCVER=7.8.4
251
-
- CABALVER=1.22 GHCVER=7.10.1
252
-
- CABALVER=1.22 GHCVER=7.10.2
253
-
- CABALVER=head GHCVER=head # see section about GHC HEAD snapshots
254
-
255
-
# Note: the distinction between `before_install` and `install` is not important.
Basic idea: Generate a `cabal.config` file during the build job (before installing the build-dependencies) constraining to HP package versions, e.g. for HP 2013.2.0.0 the `cabal.config` would need to contain the following constraints definition:
Use [this `.travis.yml` script](.travis.yml) as a template if you want
297
-
to test against Haskell Platform configurations.
298
-
299
-
### Alex & Happy with GHC ≥ 7.8
300
-
301
-
If your package (or one of its dependencies) contain Alex/Happy generated parsers, GHC 7.8.1 and later require a more recent `alex`/`happy` executable installed (see [Happy, Alex, and GHC 7.8](http://ro-che.info/articles/2014-03-08-happy-alex-ghc-7.8.html) for the gory details). The following snipped (stolen from `lens`'s [`.travis.yaml`](https://github.com/ekmett/lens/blob/master/.travis.yml)) illustrates how to this can be accomplished:
302
-
303
-
```yaml
304
-
- |
305
-
if [ $GHCVER = "head" ] || [ ${GHCVER%.*} = "7.8" ] || [ ${GHCVER%.*} = "7.10" ]; then
- Snapshots of current GHC development snapshots from the `master` branch (aka *GHC HEAD*) are uploaded at irregular intervals to the PPA
316
-
- You can select *GHC HEAD* at your own risk by setting `GHCVER=head`
317
-
- As GHC HEAD is experimental and likely to cause build failures, you might want to [tolerate failures](http://about.travis-ci.org/docs/user/build-configuration/#Rows-That-are-Allowed-To-Fail) by adding the following snippet to your `.travis.yml`:
318
-
319
-
```yaml
320
-
matrix:
321
-
allow_failures:
322
-
- env: CABALVER=head GHCVER=head
323
-
```
324
-
325
-
- NB: the line in `matrix.allow_failures.env` must match exactly
326
-
(including any whitespace) the line specified in `env`
327
-
328
-
Ideas for Additional Checks
329
-
---------------------------
330
-
331
-
- Check for `build-depends` excluding latest package versions with [`packdeps`](http://hackage.haskell.org/package/packdeps)
332
-
- Check for unused `build-depends` with [`packunused`](http://hackage.haskell.org/package/packunused)
333
-
- Check for 100% Haddock coverage
334
-
- Check for trailing whitespaces and/or tabs in source files
335
-
336
-
Random Remarks
337
-
--------------
338
-
339
-
- If you want to know which core library version each GHC used (e.g. for deciding on what upper/lower bounds to declare for `build-depends`), see [GHC Boot Library Version History](http://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries/VersionHistory)
340
-
- Supporting GHC versions prior to 7.0.1 requires more effort:
341
-
- GHC 7.0.1 was the first version to support `default-language: Haskell2010`
342
-
- Declaring `cabal-version >= 1.10` makes it more difficult to compile with GHC 6.12.3's default `cabal-install`
343
-
- `cabal-install` [falls back to top-down solver for GHC < 7](http://stackoverflow.com/questions/16021645/what-does-cabals-warning-falling-back-to-topdown-solver-for-ghc-7-mean) which may require additional tweaks to the build script to compensate for (e.g. installing `QuickCheck` via `cabal install --only-dep` is known to fail)
98
+
Sometimes you may need to regenerate CI script, for example, when
0 commit comments