Haskell CI: add GHC-9.12.0

[andreasabel]

• Haskell CI: add GHC-9.12.0
• CHANGELOG for 1.1.0.2

Candidate: https://hackage.haskell.org/package/generic-data-1.1.0.2/candidate

A release is needed for stackage:

• base-orphans-0.9.3 commercialhaskell/stackage#7599

[andreasabel]

I published 1.1.0.2.

[andreasabel]

Looks like GitHub is an inconsistent state, which prevents me from merging this PR:

$ git push --force --follow-tags
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote: error: GH006: Protected branch update failed for refs/heads/master.
remote: 
remote: - Required status check "Haskell-CI - Linux - ghc-9.8.2" is expected.
To github.com:Lysxia/generic-data.git
 ! [remote rejected] master -> master (protected branch hook declined)
error: failed to push some refs to 'github.com:Lysxia/generic-data.git'

[andreasabel]

Closing/opening does not seem to help

Haskell-CI - Linux - ghc-9.8.2 Expected — Waiting for status to be reported

The problem is that this check isn't run anymore, we are checking with 9.8.4 instead now.
So GH can wait forever for the "status to be reported", as the there is no entity anymore that could deliver such a report.

@Lysxia I leave this to you. Maybe you have to override this with admin powers. But also, it seems that the GH logic is broken, and maybe the branch protection rules have to be relaxed lest we get in this situation again with the next CI update.

[Lysxia]

I've updated the branch rules with the new GHC versions. One way to make this more robust is to not include the full GHC version number in the workflow names, only the major version numbers (9.10 instead of 9.10.1), because we can only tell Github to check for specific workflow, we can't give it some glob pattern to match against.

[andreasabel]

Thanks!

One way to make this more robust is to not include the full GHC version number in the workflow names, only the major version numbers (9.10 instead of 9.10.1)

The CI is auto-generated by haskell-ci and this tool insists on the full version number. E.g. it will complain that GHC 9.10 isn't recognized if you write tested-with: GHC==9.10 in the .cabal file instead of ...==9.10.1. So there isn't an easy way to do this.

One could limit the branch protection to mention only the "finished" GHC versions, e.g. 9.4.8 and below. There won't be minor releases any more for them, so they will be unaffected by CI updates.
Also, is so much branch protection needed for a package that sees few updates?

[Lysxia]

It's not really necessary. The main motivation for me is automerge. I'm going to remove it because the rules around it are rather inflexible for personal repositories. It seems that only I can modify the protection rules or bypass it, and I can't give you an equivalent role.