I use bitbucket caches with my builds. At the end of my build, I'd like to clear the cache and re-upload it (to cache anything additional the most recent build created).
I've tried using this plugin: https://bitbucket.org/atlassian/bitbucket-clear-cache/src/master/
However, when I get to the end of the pipeline, the cache is not re-uploaded even though it has been cleared by the plugin. The pipeline seems unaware that the plugin has cleared the cache.
name: Build and Test
# cache hit happens in setup
# cache is cleared by plugin
- pipe: atlassian/bitbucket-clear-cache:3.0.0
# BUG? in teardown, pipelines doesn't re-upload the gradle cache
@Andrew Kent the pipe you are using is only clearing cache and not responsible for reuploading.
I think it would be useful to specify the cache for the pipe, you want to clear, and it will clear only specific cache you put like
.If you clear the same cache and reupload it again, there is no sense to use clear-cache, but if you want to reupload some specific things, you just may not type this specific cache in the CACHES variable and it will not be cleared.
If you want some another thing to upload specific caches, you can write your custom pipe, because right now we did not consider this change (but will report this if it would be really needed).
Besides that, we are going to release the pipe you're using soon, right now it is not official.
My scenario (often) is:
As a final step, I'd like re-upload the 100% built cache (so I don't have to start at 70% every time until the cache expiration period is hit).
I was hoping the cache-clear plugin would solve my needs, but if I clear mid-run the cache is not re-uploaded at the end of the pipeline because there was a cache hit at the start (pipeline doesn't have the smarts to realize the cache was cleared mid-run).
Is there any way to accomplish this?
@Matthew Painter it's very typical of Atlassian products and the community. I imagine what happens is this:
- persona A inherits a project that uses bitbucket
- persaon A tries to solve a long standing ignored internal problem that is now causing a blocker
- persona A delivers approach X to the problem that only works some of the time and cost the company a lot of time and represents a large maintenance cost in future.
- persona A discovers that the maintenance cost and the problem is more easily solved by moving to github.
- person B discovers approach X by person A, requests comment...
- thousands of years pass.