epic: Release `v2.5.0`

[gencer]

Release v2.5.0

• [ ] #16
• [ ] #36
• [ ] #45
• [ ] #44
• [ ] #48
• [ ] #49
• [x] #46
• [ ] #47
• [ ] #51

[filipecaixeta]

@gencer do you plan to release 2.5.0?

[gencer]

@filipecaixeta Yes. However, due to local issues I was unable to do so in time. I'll be on this ASAP.

[jebentier]

@gencer Checking in here on the timeline for this release. Some of these enhancements would be great for us to be able to use more easily.

[gencer]

Deeply sorry for the delay. The project is alive and still new features are coming but this epic still needs my attention.

Could you please tell me a few most important tasks from above currently you are waiting for?

[jebentier]

Not to worry. I’m also happy to assist in the development if you would like the help. For us it’s the ability to always push the new cache even when there is a cache hit because the cache content will update without the key changing.

[gencer]

Not to worry. I’m also happy to assist in the development if you would like the help.

Absolutely. Thank you for the help.

For us it’s the ability to always push the new cache even when there is a cache hit because the cache content will update without the key changing.

So, should we skip upload if cache hits OR should we always upload? Could you please be more specific on this? Because both requests are in the above epic list :)

[jebentier]

So, should we skip upload if cache hits OR should we always upload? Could you please be more specific on this? Because both requests are in the above epic list :)

Certainly. Ultimately I think this should be configurable. I think it's a reasonable assumption that by default a cache hit means there's no need to re-upload the same cache when the step completes. But being able to set reupload_on_hit: true or equivalent in the plugin configuration would be helpful for us.

[jebentier]

@gencer I went ahead and made #59 to add this functionality based on the spec you put in #47