Move to travis-ci.com ?

[mmhat]

From travis.org:

Please be aware travis-ci.org will be shutting down by end of May 2021. Please consider migrating to travis-ci.com.

[mmhat]

Doing a bit of research revealed the following:

Apparently one gets 10000 Credits/month with the "Free" plan. One minute MacOSX build time costs 50 Credits which leaves us with 200 minutes/month build time. IMHO this won't fit our needs. I see two options:

1. Upgrade to another plan.
2. Migrate away from Travis.

Thoughts?

[mmhat]

Judging from this other projects are hit by this as well. Some posts are really devastating.
For the record: Announcement blog post

@Gabriel439 I guess it was you who set up the CI initially? What are your ideas on that?

[Gabriella439]

@mmhat: I don't have any particular attachment to Travis CI. The only reason we still kept it around was to build executables for Mac, but we can probably do that with GitHub actions now

[sjakobi]

CC @f-f who had introduced the Mac executable building in #1101, in case he has any thoughts on this issue.

[mmhat]

I started some development on the this branch. So far the results look promising. Have a look at the "Actions" tab :)

[mmhat]

While working on this I stumbled upon the following line in our AppVeyor configuration:

Enable when issue with path-separators tests on windows is resolved

@german1608, can you clarify which issue that line is referring to? Is it still an issue or got it resolved?

[mmhat]

Is there any particular reason why we don't want the stack.yaml.lock file to be checked in? The documentation suggests that it should be.
@ejconlon @jneira What was the motivitation behind the inclusion in the .gitignore file?

[sjakobi]

Is there any particular reason why we don't want the stack.yaml.lock file to be checked in? The documentation suggests that it should be.

@mmhat I'm not sure we need this level of reproducibility. I'd expect that main thing that we'd get from tracking the stack lock files is inflated commit diffs.

[mmhat]

@sjakobi It is rather about cachability: The way how actions/cache works is that you commit to a key for your cache once. After a successful build that cache gets populated and never updated again. To work around outdated caches it is common to do something like this:

key: ${{ hashFile(some lock file here) }}

If that file changes a new cache is created and the old one will be deleted if not accessed for one week.
The best explanation I found is in this blog post.
There are some examples in the official documentation but the one for Haskell is unfortunately not the best one. IMHO it is better to look at the ones of the other languages listed there.

The problem regarding commit diffs is understandable; I will try to work around that, i.e. look for a way to get decent caching without that file.

[sjakobi]

How about simply using the stack.yaml as the cache key file?

Do note though that CI times are usually dominated by the Hydra build, so optimizing the GA build probably isn't too important.

If tracking the stack.yaml.lock has clear advantages, I wouldn't be opposed to doing that either.

[mmhat]

@sjakobi I went for hash of stack.yaml as a key after I figured out that there is no way to generate the stack.yaml.lock without a stack setup. I'm aware of the Hydra being the bottleneck here but I guess it was nice if some CI job provides a faster feedback for the developer.

BTW: Is there a way to speed up the Hydra builds? What are the limitations there?

[mmhat]

Ok, I managed to port most of our CI code to GHA. Two (probably related) problems remain:

• Test failures of the following packages on Windows: dhall, dhall-docs and dhall-json. In all cases the golden tests fail.
• dhall-yaml fails on Windows due to wrong line endings.

I will try to resolve those issues in the next days; Any ideas on how to fix them are of course highly appreciated :)

[mmhat]

Closing since #2199 got merged.