Build macOS binaries with Travis

[f-f]

Fix #737

This PR changes the Travis build (I'm replacing the current one which I don't understand with the one from spago which I mostly wrote) to compile macOS binaries and push them to GitHub releases alongside the Linux and Windows binaries.

Things left to do:

• enable the Travis integration (I don't have access to it)
• add an $API_KEY variable to authenticate to GitHub (though I can reuse the current $GITHUB_OAUTH_TOKEN if it's still there)
• verify that packaging is all fine, and move the tar operations to the before_deploy section

[jneira]

Travis has experimental windows support, so you can build in the three envs, what do you think?

[f-f]

@jneira the only purpose of this Travis build is to output macOS binaries, so I wouldn't want to enable anything else on the matrix (since we already build Windows on Appveyor and Linux on Hydra)

[jneira]

Yeah, i was thinking in remove appveyor (but keep nix) to somewhat unify the ci, appveyor has one hour of build time limit
And maybe add a linux build to test it without nix

[f-f]

@jneira I see. I really don't like Travis, I'd say if we have to setup out new CI builds we could try Azure. Recently both stack and haskell-ide-engine switched to it

EDIT: oh I just realized you said basically the same thing in #1063 😄

[jneira]

Yep, my idea is to use only one, travis already has cache support and azure has stable windows env and more concurrent jobs (i think).

[joneshf]

As someone that's done work in this file, lemme say that this looks great! I look forward to seeing this working again!

I left a few superficial comments. Feel free to ignore them or follow them, whatever you feel like.

[Gabriella439]

@f-f: Alright, Travis is enabled with a GITHUB_OAUTH_TOKEN installed, but you'll need to trigger a new change to test it on this pull request

[Gabriella439]

@f-f: Hmmm. For some reason Travis doesn't seem to be registering the existence of your pull request. You might have to close and reopen your pull request

[Gabriella439]

When this is enabled, will be running this on pull requests or just the master branch and tags?

[f-f]

When this is enabled, will be running this on pull requests or just the master branch and tags?

It will build PRs, master and tags. There is the following rule in the config, that might be confusing in this regard:

# Build only master and release tags
branches:
  only:
  - master
  - /^\d+\.\d+\.\d+(\.\d+)?$/

This is to prevent other branches from being built, because they are covered by Travis' "PR builds", otherwise you'd get two builds from every PR with a branch in this repo (and if you disable "branch builds" in Travis then you don't get builds for releases at all)

[paulyoung]

This is great! Can we expect a release soon that includes these binaries?

[f-f]

@paulyoung yep, once Dhall 9 is out (sometime in the coming days) there will be a matching release for the Haskell package too

[Gabriella439]

@f-f: Thank you for doing this! 🙂

[f-f]

You're welcome 🙂

[paulyoung]

@f-f it occurred to me that the binaries built by Travis might be available somewhere in the meantime. Is that the case?

[f-f]

@paulyoung the binaries are indeed build at every CI run, but they are not uploaded anywhere, so they get "lost" after the build is done (and there's no way to recover them as far as I know)

[paulyoung]

Now that Dhall 9 has been released, is there a timeframe for a new dhall-haskell release?

[Gabriella439]

@paulyoung: ~3 days. I'm going to begin the process of cutting the release tonight

[Gabriella439]

@paulyoung: The executables are available now from the releases page: https://github.com/dhall-lang/dhall-haskell/releases