Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
T
tahoe-directory
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Package Registry
Model registry
Operate
Environments
Terraform modules
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
This is an archived project. Repository and other project resources are read-only.
Show more breadcrumbs
PrivateStorage
tahoe-directory
Commits
35f63083
Commit
35f63083
authored
1 year ago
by
Jean-Paul Calderone
Browse files
Options
Downloads
Patches
Plain Diff
disable gitlab caching for cabal files
it's error prone, files go missing
parent
297c0400
No related branches found
No related tags found
1 merge request
!3
disable gitlab caching for cabal files
Pipeline
#4750
passed
1 year ago
Stage: test
Changes
1
Pipelines
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
.gitlab-ci.yml
+0
-34
0 additions, 34 deletions
.gitlab-ci.yml
with
0 additions
and
34 deletions
.gitlab-ci.yml
+
0
−
34
View file @
35f63083
...
...
@@ -24,41 +24,7 @@ hlint:
# Use cabal to build the library and test suite and then run the test suite.
cabal-build-and-test
:
cache
:
# The cache is additive. We can aways push more objects to it. The cabal
# system uses a hash mechanism so that different builds will never collide
# with each other. We can probably safely add to a single cache
# indefinitely so we don't try to make come up with a fancy cache key.
# Compared to trying to use a hash of our dependencies (or, eg, the .cabal
# file itself) as a cache key, this saves us a lot of rebuilding when we
# have a minor change in dependencies or packaging metadata. The possibly
# shortcoming of this approach is that the cache will grow without bounds
# as our dependencies change. It would be nice if there were a way to
# trim stale dependencies from it periodically.
key
:
"
v0-cabal"
# Even if a build fails (eg because of a test suite failure or because the
# job timed out because building things took too long), there will be
# useful build artifacts worth caching - perhaps some new dependencies
# will have been built, for example. We may as well cache these.
when
:
"
always"
# These paths are resolved relative to the project directory.
paths
:
# Cabal normally writes this directory to $HOME. However, we override
# this (in the job script) to put the directory into the project
# checkout, since that's the only place we can cache files from.
-
"
.cabal"
script
:
-
|
# Configure cabal to put its caches beneath the project directory.
# This is only done in CI configuration because non-CI users probably
# want their local cabal configuration left alone.
cat >cabal.project.local <<EOF
store-dir: $CI_PROJECT_DIR/.cabal
remote-repo-cache: $CI_PROJECT_DIR/.cabal/packages
EOF
nix run .#cabal-test
# Use nix to build the library and test suite and run the test suite.
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment