search

hendrikmuhs / ccache-action

github action to speedup building using ccache
MIT License
122 stars 54 forks source link

Updating the `v1` tag #111

Closed bjorn closed 1 year ago

bjorn commented 2 years ago

Is there any particular reason the v1 tag is stuck on a very old version, and the README.md recommends specifying hendrikmuhs/ccache-action@v1.2?

As far as I understood, in GitHub Actions @v1 is generally expected to take the latest 1.x version, since a 2.x version might break compatibility.

My questions is prompted by me getting "Node.js 12 actions are deprecated" warnings regarding the use of this action, and I wonder if I should update my workflows to use @v1.2 (and potentially miss out on improvements in a future 1.3 release) or whether you could update the v1 tag in this repository to match v1.2.3 rather than v1.0.5.

tupaschoal commented 2 years ago

That's a good question, the docs even mention moving https://docs.github.com/en/actions/creating-actions/about-custom-actions#using-tags-for-release-management (kudos to @Trass3r for sending me this)

jonashaag commented 2 years ago

I think we should delete the v1 tag or rename it to v1.0.0. IIUC GHA will automatically use vX.* if you specify vX but in this particular case we have a tag vX so I guess it doesn't apply those rules?

hendrikmuhs commented 2 years ago

No reason, the v1 tag should have been the v1.0 tag.

I actually think the readme should not recommend a tag that gets slid by me, this is not good practice in terms of security. It is better to pin the version explicitly and recommend depandabot for updating. (If anyone wants to re-work the Readme, feel free).

Because I don't know the usage of the v1 tag (I can't see usage in private repos!), I rather don't delete it for now. Therefore the only option would be forwarding it to v1.2.

bjorn commented 2 years ago

I actually think the readme should not recommend a tag that gets slid by me, this is not good practice in terms of security. It is better to pin the version explicitly and recommend depandabot for updating. (If anyone wants to re-work the Readme, feel free).

Those worried about security would need to use the commit hash, because anything else (tag / branch) can be moved by you. There is zero difference in referring to your v1 or v1.0.5 tags, in terms of security.

Personally I'd rather trust you though, and benefit from the latest security fixes without needing to update my workflow file, and then needing to rely on a bot to remind me about it.

Because I don't know the usage of the v1 tag (I can't see usage in private repos!), I rather don't delete it for now. Therefore the only option would be forwarding it to v1.2.

What matters is whether your v1.2 version is compatible with v1 in terms of how this action is used. If it isn't compatible, then v1.2 should have been a v2. If it is, then you're saving everybody who specified v1 the need for a manual update to fix those Node.js 12 deprecation warnings. :-)

I see the v1 tag is now moved to v1.1.1. Does that mean you're worried about a compatibility issue with v1.2?

Trass3r commented 2 years ago

True compatibility in the sense of semantic versioning is what counts here. Otherwise I'd just use main directly to always get the latest fixes.

hendrikmuhs commented 2 years ago

I see the v1 tag is now moved to v1.1.1. Does that mean you're worried about a compatibility issue with v1.2?

no, the v1 tag is still the same sha as 1.0.5

I had a look at the history and code: v1.2 changes the lookup in the github cache, therefore moving v1 to v1.2 changes the way lookup works, the impact: a v1 cache can not be loaded into v1.2, so what will happen: the cache isn't restored and the 1st new build starts fresh with a long build time. Other than that there are no breaking changes in terms of the API (config). So by definition this isn't a major change.

I am willing to move v1 to v1.2 and keep it updated in future. Please shout if you disagree with the above assessment, otherwise I will move the tag some when in the next days.

True compatibility in the sense of semantic versioning is what counts here.

Agreed of course. But please note: This is a small hobby project, actually just a side project for my main project. Decisions have been made best effort, preferring progress over perfection. I appreciate the positive usage numbers of course, just don't expect a perfect product.

Otherwise I'd just use main directly to always get the latest fixes.

Strongly discouraged, as I proofed yesterday, I break stuff on main and even a release doesn't guarantee quality.

hendrikmuhs commented 1 year ago

I've updated the v1 tag with the last releases. Closing.