Add Bitbucket cache configuration doc#14113
Conversation
| key: | ||
| files: | ||
| - composer.lock | ||
| - "**/*.php" |
There was a problem hiding this comment.
"**/*.php" this doesn't make sense to me, it'd mean that when any .php file changes, the cache is invalidated?
There was a problem hiding this comment.
That is correct. That makes no sense. I probably misconfigured our pipeline then 🤦 Let me remove that portion and re-run a pipeline.
There was a problem hiding this comment.
They also offer the ability to bypass the cache invalidation logic and just always cache the directory, it's possible to do that too.
definitions:
caches:
bundler: vendor/bundle
pipelines:
default:
- step:
caches:
- bundler #cache is defined above in the definitions section
script:
- bundle install --path vendor/bundleThere was a problem hiding this comment.
Only invalidating on composer.lock seems to work. The static analysis step dropped to basically they time it takes to clone and setup the env
There was a problem hiding this comment.
I'm happy to try any other configurations if you want to check anything else.
There was a problem hiding this comment.
Running across branches works
There was a problem hiding this comment.
I can simulate a failure in the phpstan step and in another step and see what the behavior is.
The teardown step is where the cache(s) get uploaded, here's a sample:
You already have a 'composer' cache so we won't create it again
You already have a 'phpstan' cache so we won't create it again
musl libc (x86_64)
Version 1.2.5
Dynamic Program Loader
Usage: /lib/ld-musl-x86_64.so.1 [options] [--] pathname
Cache "composer: ~/.composer/cache": Skipping upload for existing cache
Cache "phpstan: /tmp/phpstan": Skipping upload for existing cache
Searching for test report files in directories named [test-reports, surefire-reports, failsafe-reports, test-results, TestResults] down to a depth of 4
Finished scanning for test reports. Found 0 test report files in 0 seconds.
Merged test suites, total number tests is 0, with 0 failures and 0 errors in 0 seconds.
Compressed step metrics file to 430 B in 0 seconds
Uploading step metrics of 430 B.
Successfully uploaded step metrics in 0 seconds.
There was a problem hiding this comment.
It will skip caching if the step using the cache fails. Let me check next if a step not using the cache fails.
There was a problem hiding this comment.
When another step not using the cache fails:
If the phpstan cache already exists it will skip
If the phpstan cache doesn't exist but the step using the cache passes, it will upload
There was a problem hiding this comment.
If the step exits with a success code the cache is still uploaded, but that would mask the phpstan failure in the UI
|
@ondrejmirtes I ran some more tests and attached screenshots. Here's a summary of what I've found:
|
|
We want the cache to be updated even when PHPStan fails. Let's say PHPStan has to run fully because you changed config and it finds 5 errors. If you persist the cache and then run it again after modifying 1 file, it will run much faster. If you don't persist the cache and modify 1 file, it will have to run full analysis again. |
|
I don't know if that's possible. According to the cache documentation :
If the phpstan process exits with a non-0 code when there are issues, then it seems like the caching step will be skipped. I've opened a community post on Atlassian's website to see if there is a way around that. |
|
@ondrejmirtes an Atlassian team member confirmed the limitation:
I can update the PR further to indicate the limitation, or if you don't want the potential additional maintenance overhead with issues that might result from this limitation, I can close this. I think it can still provide some value to configure the cache, even it isn't as flexible or usable as GH or GL. Thanks for the time and consideration either way! |
2 participants
No description provided.