Overhaul metadata merging and add 'ghcup config add-release-channel URI'
Wrt #328 (closed) @abel
This PR does two things:
- makes merging release channels more robust (previously we would only merge versions if the tool exists in the main channel)
- adds cli support, so to get pre-releases you would do:
ghcup config add-release-channel https://raw.githubusercontent.com/haskell/ghcup-metadata/master/ghcup-prereleases-0.0.7.yaml
This might make adding pre-releases easier as described in #328 (comment 414294)
So a github workflow would look as follows:
jobs:
build:
runs-on: ${{ matrix.os }}
strategy:
fail-fast: false
matrix:
os: [ubuntu-latest, macOS-latest, windows-latest]
ghc: ['8.10.7', '9.3.2.20220308']
cabal: ['3.6.2.0']
steps:
- uses: actions/checkout@v2
- name: enable pre-releases
run: ghcup config add-release-channel https://raw.githubusercontent.com/haskell/ghcup-metadata/master/ghcup-prereleases-0.0.7.yaml
shell: bash
- uses: haskell/actions/setup@v1.2
with:
ghc-version: ${{ matrix.ghc }}
cabal-version: ${{ matrix.cabal }}
Obviously, this will only work for windows if https://github.com/haskell/actions/issues/70 is merged. But since ghcup
is pre-installed on ALL github environments, you can simply drop haskell/actions/setup@v1.2
and do this instead:
- name: Install ghc/cabal
run: |
ghcup install ghc --set ${{ matrix.ghc }}
ghcup install cabal ${{ matrix.cabal }}
Merge request reports
Activity
143 ) base 144 newGlobalTools = M.union base2 ext2 145 in GHCupInfo tr newDownloads newGlobalTools 130 ext <- liftE $ sequence $ fmap (either pure getBase) exts 131 mergeGhcupInfo (base:ext) 132 133 where 134 mergeGhcupInfo :: MonadFail m 135 => [GHCupInfo] 136 -> m GHCupInfo 137 mergeGhcupInfo [] = fail "mergeGhcupInfo: internal error: need at least one GHCupInfo" 138 mergeGhcupInfo xs@(GHCupInfo{}: _) = 139 let newDownloads = M.unionsWith (M.unionWith (\_ b2 -> b2)) (_ghcupDownloads <$> xs) 140 newGlobalTools = M.unionsWith (\_ a2 -> a2 ) (_globalTools <$> xs) 141 newToolReqs = M.unionsWith (M.unionWith (\_ b2 -> b2)) (_toolRequirements <$> xs) 142 in pure $ GHCupInfo newToolReqs newDownloads newGlobalTools added 1 commit
- 2b6d9707 - Overhaul metadata merging and add 'ghcup config add-release-channel URI'
@abel opinions?
Er, I have very much of a user perspective on this. Basically, I am mostly using
haskell-ci
which defines its own set of supported GHC versions. When an new head RC is available it is usually put there (replacing the latest head). If I generate a CI withhaskell-ci
using the head RC there, it relies onghcup
to install it. However, ifghcup
drops the RC before I have updated the CI, my CI breaks, falsely suggesting the package broke. I thinkhaskell-ci
removes the RC once the proper GHC release is out (probably also to keep the list of supported version clutter-free). So, I would not be able to regenerate the CI with the RC (but also, I would not want this, why should I?). Yet, while I am not regenerating it, I would continue to work. This motivates my wish that ghcup should not drop knowledge about RCs quickly (even if it stops advertising them).Well, my point is that
haskell-ci
would need a patch to enable the ghcup RC channel, e.g. here:by running
"$HOME/.ghcup/bin/ghcup" config add-release-channel \ https://raw.githubusercontent.com/haskell/ghcup-metadata/master/ghcup-prereleases-0.0.7.yaml
changed milestone to %0.1.17.6
Merged: 8eeb32c4