actions
actions copied to clipboard
Remove cabal update from setup
I feel like cabal update
should not be part of the setup. This is because cabal update
will do project specific work and sometimes fail because of problems specific to the project.
For example:
Aside from this, the project may want to do cabal update
after configuring the project, which duplicates work.
Aside from this, I've see the fatal: repository ... not found
error multiple times today in more than one project. Has anyone else experienced this? Is this a Github infrastructure issue?
Would it make sense to change it to cabal update hackage.haskell.org
(instead of removing it)?
Possibly. Does that avoid cloning all the repositories?
I thought it would, but a quick test shows it does not. :-(
This works cabal update --project-file=$(mktemp)
But perhaps not on windows
I've gotta say, I truly appreciate your ability to run headfirst into every corner case known to man. It's quite the talent :)
Running cabal update has been left in thus far because it was something that was done in the action originally and I didn't want to make a breaking change without bumping the major version.
Now that I can commit to the repository and have better control over versioning, removing cabal update from the action makes sense; I haven't actually seen any workflows that don't run cabal update on their own, anyway.
That all said.
This is because cabal update will do project specific work and sometimes fail because of problems specific to the project.
ughhhhhhhh (╯°□°)╯︵ ┻━┻
I'd also appreciate the ability to disable cabal update
. Not just cabal update
actually, I'd love to be able to disable cabal installation entirely, without also disabling ghc installation.
Why I want this: when I let stack install ghc and then cache ~/.stack
, the entire ghc installation (couple hundred MB) is cached for each job. With a somewhat elaborate build matrix, we're getting fairly close to the 5GB github actions cache limit. Therefore I'd like to let stack use the system ghc, but haskell/actions/setup
insists on also installing cabal and performing cabal update
, which takes an additional 30+ seconds and wastes bandwidth.
Oh, turns out I can just do:
sudo apt install -y ghc-${{ matrix.ghc }}
echo /opt/ghc/${{ matrix.ghc }}/bin >> $GITHUB_PATH
(full context: https://github.com/xmonad/X11/commit/ebaff90eda7e9136314144c048ceea304ccbfc0f)
Wouldn't be as simple if I wanted this to work on Windows and MacOS as well, but those aren't relevant for xmonad, so I'm fine for the time being. :-)
@liskin: I think stack-no-global: true
does exactly what you want (only install stack
, not ghc
nor cabal
).
@hazelweakly wrote:
didn't want to make a breaking change without bumping the major version.
That would mean this cannot appear before v3.0.0
?
Fixing the OP is a simple as removing one line: https://github.com/haskell/actions/blob/04b033e3781183ec427f3258b8fe3e5a484e3d25/setup/src/setup-haskell.ts#L76
PR:
- #29
@liskin: I think
stack-no-global: true
does exactly what you want (only installstack
, notghc
norcabal
).
Well there's a reason I typeset the "without also disabling ghc installation" part in bold…
Doing "exactly what I want" would have been making sure the desired versions of both slack and ghc are installed, but skipping cabal and cabal update. I don't think stack-no-global: true
does that.
Anyway, all this stopped being relevant (for me) with the hvr-ghc PPA no longer being maintained. Having the haskell GH action install ghc via ghcup is no faster than having stack install it, so I can just use the GHA-provided stack and ignore this action entirely.
@newhoggy wrote:
I feel like
cabal update
should not be part of the setup. This is becausecabal update
will do project specific work and sometimes fail because of problems specific to the project.
In simple CI, you'd want cabal update
to have run. Maybe we could have a new input cabal-update: false
to turn off cabal update
.