Psalm caching in CI could probably be enhanced by read-only cache access option #4883
nicholascus
started this conversation in
General
Replies: 2 comments 2 replies
This comment has been hidden.
This comment has been hidden.
-
Sharing cache folder across multiple branches is not safe. Psalm relies on file modification times to check if the file cache could be used, so you may get issues due to the incorrect file cache version being used (where file cache means cached representation of a file). Using mtimes also means you need to do an additional step in your build pipeline to restore the file modification times for cache to be effective, as git doesn't store mtimes. I've used git-restore-mtime with some success. Have you thought about giving each build their own copy of persisted cache? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'm trying to setup Psalm analysis on Jenkins build server for all PRs and branches.
Obvious choice was to use filesystem cache as an easiest way to accelerate build on pull requests.
On my project full scan takes ~7 minutes, cache based scan could take as little as 6 seconds.
Jenkins creates workspace and checkout project files to a new location for each PR or branch, and then it runs builds on new commits to the branch/PR in the same folder.
Using self hosted build agents I could safely share Psalm cache location for multiple build. I was running Psalm in docker container with
~/.cache/psalm
host location added as a volume to container~/.cache/psalm/
.With multiple builds running in parallel I found some psalm runs finish with error exit code.
I also tried using read-only option for cache volume but psalm was finishing with error on attempt to 'create' folder.
I ended up using a PR/branch build workspace local cache locations which don't give enough execution speed gain as many PRs would only have one commit and the build on that first commit would require full scan and take 7 minutes.
My hope with the psalm cache was that I would be able to use it read only on all branch/PR builds and then run the nightly develop branch build with read-write access to file cache.
Ideal solution would be to have an option for read-only access to the cache, which would still recreate cache when it finds cache not existing (where further enhancement would be filesystem based locking for priming of cache for specific project key).
Could somebody suggest if the direction of thinking I had was right and whether there is the right way of setting up psalm cache in multibranch concurrent build environment?
If this use case is not supported yet is it a good new feature for Psalm, how much development work would be to implement that and is it something a person new to the project (like me) could be trying to do?
Beta Was this translation helpful? Give feedback.
All reactions