9 Commits

Author	SHA1	Message	Date
github-actions[bot]	7cb14762cb	ci: Regenerate haskell-ci	2024-03-02 03:14:55 +00:00
github-actions[bot]	31f63bb162	ci: Regenerate haskell-ci	2024-01-17 11:52:56 +00:00
Tomas Janousek	f2aa84e102	ci: Only build haddock for hackage with the latest GHC ... Cabal 3.10.2.0 exposes a bug in Haddock shipped with GHC 9.0 and 9.2, so we need to work around it by bumping the version of GHC/Haddock we use for building/uploading docs to Hackage, and to prevent build failures we don't ever try to build haddocks for Hackage with older versions of GHC/Haddock. Related: https://github.com/haskell/haddock/issues/1582#issuecomment-1611412223 Related: https://github.com/haskell/cabal/issues/8326 Related: https://github.com/haskell/cabal/issues/9060 Related: https://github.com/haskell/cabal/pull/9073 Related: https://github.com/haskell/cabal/pull/9049	2023-11-12 23:57:40 +00:00
Tony Zorman	b394435443	ci: Test against GHC 9.6.1 ... + Regenerate haskell-ci and adjust relevant patches. - Remove haskell-ci-dependabot.patch, as it is no longer necessary. Related: xmonad/xmonad-contrib@635711e994	2023-03-31 07:46:37 +02:00
Tomas Janousek	2502fd8d55	ci: Bump actions/* to v3 in haskell-ci workflow ... This gets rid of the deprecation warnings about https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/	2022-11-27 17:38:41 +00:00
slotThe	a854cdaf9b	ci: Update supported GHC versions ... + Prefer GHC 8.10.7 to 8.10.4, as versions seem to have stabilised now. + Add support for Stackage LTS 19; this ships with GHC 9.0.2. + Since a new version of 9.2 has been released, prefer 9.2.2 over 9.2.1. Related: https://github.com/xmonad/xmonad-contrib/pull/694	2022-04-05 14:33:23 +02:00
Tomas Janousek	9f64c2ca90	ci: Show error body from Hackage when it fails ... Prevents having to upload the candidate manually to see what's wrong.	2021-11-08 18:14:52 +00:00
Tomas Janousek	9849800dc5	ci: Swap candidate/final release logic ... During the release of xmonad 0.17.0, I realized that we need to be able to upload candidates before tagging the release on GitHub, because there might be issues with the tarball and Hackage may reject it. When that happened, I had to remove the release, delete the tag, upload the candidate manually to see what's wrong with it, try to fix it, upload it manually again, and so on. This commit swaps the logic: when the workflow is invoked manually, it uploads the candidate. This can be done multiple times, and once everything is fine, the release can finally be tagged and it's released to Hackage proper. The only disadvantage is that we need to remember to try uploading the candidate. Not sure if there's a perfect solution…	2021-11-08 18:13:23 +00:00
Tomas Janousek	85787ce059	Automate and document releasing to Hackage ... Pioneered in https://github.com/xmonad/X11, this adds automation for Hackage releases and updates MAINTAINERS.md with simplified instruction for the release procedure. Related: https://github.com/xmonad/xmonad/issues/75 Related: https://github.com/xmonad/xmonad/issues/264 Related: https://github.com/xmonad/xmonad-contrib/issues/393	2021-07-24 18:13:11 +01:00