Fix CI

[pbrisbin]

This migrates to our newer stack-all-based setup, with stack-ltsX.yaml files (not X.Y) and makes stack.yaml a symlink to the latest. It also updates CI to use generate-matrix and installs the PCRE lib now needed that ubuntu-latest is 24.04.

I spent some time trying to get nightly to work too, but it seems Very Hard.

[chris-martin]

Why keep nightly? I have never understood what's the point of having Stack configs that we know don't work.

[pbrisbin]

what's the point of having Stack configs that we know don't work

It not working is a temporary issue and not something we seek to do or expect to be the case.

Why keep nightly?

It's part of our general policy and process for keeping our packages in Stackage at all:

If you were to remove your upper bounds and do nothing else, your packages would invariably drift into a broken state over time. Particularly stable libraries that rarely see updates would therefore rarely re-run CI against newer dependencies and you'd be relying purely on user-reported issues to uncover breakage.

But we do more than "nothing else". We also ensure our libraries remain in Stackage, which just so happens to rebuild against newer dependencies every single night

In other words, to avoid the maintenance of upper bounds, we want to stay in Stackage.

Given that, the thinking was that, by having a nightly build on CI, particularly one that's scheduled, we will be alerted to failures within our own CI and fix them before Stackage's own build fails and they report an Issue on our project that we have to see, triage, and address. It's just a "getting ahead of it" thing.

Less concretely, and more anecdotally, I find that dealing with things in nightly tends to amortize the hassle you see when moving LTSs anyway. It helps avoid the "big upgrade" stall, c.f. megarepo.

If that's not working, we can certainly try without our own pro-active nightly CI.

[pbrisbin]

I guess the ship sailed ages ago about keeping freckle-app specifically in Stackage -- it's both more work and not useful -- so there really is no value in the nightly build, except perhaps the "deal with issues earlier" thought, which is pretty flimsy.

[chris-martin]

Might make sense to keep the nightly config but just take freckle-app off the package list. (Moot anyway though if we're going to start making progress at splitting up the repo, which I would like to do.)

I see why we want to keep libraries up to date with the latest nightly, I just don't see how committing a failing build helps to do that. I would rather have failing update pull requests that gets merged once they work.

[pbrisbin]

I just don't see how committing a failing build helps to do that

I think I just don't characterize that as this. We're just not removing a build if it is (temporarily) failing. I suppose your suggestion is that if it fails you just remove it entirely and then what, immediately open a PR that brings it back and leave that PR open until addressed? I just don't see that as meaningfully better. I'd rather see the not-required-but-failing build on every other PR I create in the repo, to prod me to take another swing at it. Pushing it out to some PR is just removing it forever with more steps, IMHO.