search

reviewdog / action-staticcheck

🐶 Run staticcheck with reviewdog on pull requests to improve code review experience.
https://github.com/marketplace?type=actions&query=reviewdog
MIT License
18 stars 2 forks source link

Refactor from docker to composite action #16

Closed kstiehl closed 3 years ago

kstiehl commented 3 years ago

As discussed in #14 here is the refactoring of the action so that it is a composite action now.

This PR should fix #9

kstiehl commented 3 years ago

@haya14busa

Currently the staticcheck repository has a weird naming pattern for releases. Instead of the version they name the release after the day on which it was created. That makes it quite difficult to allow the user to choose the staticcheck version.

However before the refactoring we also always used the latest one, so this is not really a downgrade. Maybe you've a good idea on how we can improve that.

dominikh commented 3 years ago

Currently the staticcheck repository has a weird naming pattern for releases. Instead of the version they name the release after the day on which it was created. That makes it quite difficult to allow the user to choose the staticcheck version.

That is not quite correct. The versioning scheme is <year>.<major>.<patch>. For example, 2020.2.2 was the second patch release for 2020.2, which was the second major release in 2020. These versions are only connected to a date in that major releases are relative to the year they're made in. The next patch release for 2020.2 would be 2020.2.3, and the next feature release will (hopefully) be 2021.1.

kstiehl commented 3 years ago

@dominikh,

Ah thnx for the insights 👍 . I will adjust this PR, so that users can overwrite the staticcheck version

haya14busa commented 3 years ago

@kstiehl Thank you for the great work! LGTM :+1: As for the staticcheck version, this repo used the latest version before as you mentioned, so it's ok to merge this p-r first and work on the version-related work separately.

@dominikh Thank you for your information! I just want to confirm, but does it mean we can assume the staticcheck version format follows (or is compatible with) the semantic version format? I'd like to automate managing staticcheck version with the automated workflow (https://github.com/reviewdog/action-depup), and it's compatible with semantic version format and I wonder we can use this for staticcheck.

github-actions[bot] commented 3 years ago

🚀 [bumpr] Bumped! New version:v1.5.0 Changes:v1.4.3...v1.5.0

haya14busa commented 3 years ago

I filed #17 for the follow-up :)

dominikh commented 3 years ago

Thank you for your information! I just want to confirm, but does it mean we can assume the staticcheck version format follows (or is compatible with) the semantic version format? I'd like to automate managing staticcheck version with the automated workflow (https://github.com/reviewdog/action-depup), and it's compatible with semantic version format and I wonder we can use this for staticcheck.

Well, not precisely. <year>.<major>.<patch> does not map directly to <major>.<minor>.<patch>. For example Staticcheck 2020.2 may have changes that are not backwards compatible to 2020.1. The versions will always contain 2 or 3 dot-separated elements, but the elements do not have the same meaning as they do in semver.

There is a separate set of tags that exist explicitly to make Go modules happy. These are v0.<minor>.<patch>. 2020.2 is v0.1.0, 2020.2.1 is v0.1.1, 2021.1 will be v0.2.0, and so on. These are truly semver, but only because major version zero carries no guarantees.

In general, it's recommended to always read the release notes of Staticcheck before upgrading to a new version, which precludes fully automatic updates.

haya14busa commented 3 years ago

Thanks for the clarification! I understand it's not semantically the same as the semver, but as long as the format is <year>.<major>.<patch>, probably we can use action-depup.

In general, it's recommended to always read the release notes of Staticcheck before upgrading to a new version, which precludes fully automatic updates.

Yes! I meant I'd like to automate the update flow, especially for creating a Pull Request (like dependabot/renovate) so that we can notice new releases of staticcheck and make it easy to bump the version. We can check the release note before merging it.