Add new workflow to check for golangci-lint releases

[philippschulte]

Change summary

It's important to keep up with the latest and greatest of golangci-lint in order to prevent breaking changes for linting issues as experienced in #754.

This PR adds a new workflow/cron job which checks for new releases every hour. If a new release is detected the workflow works as follows:

• creates a new GitHub issue titled 🚀 New golangci-lint release: vX.Y.Z
• provides a link and release notes in the body

That issue stays open until a team member opens a pull request with a dependency bump which references it and closes it automatically.

If we as a team agree on this new workflow the plans is to transfer the same workflow to all of our Go projects which use golangci-lint.

All Submissions:

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

[anthony-gomez-fastly]

i think since we are using the golangci-lint github action dependabot will automatically check for new versions of that? i would also try to only run this once a day, once an hour seems a bit much if we do go forward with it

[philippschulte]

i think since we are using the golangci-lint github action dependabot will automatically check for new versions of that?

Since we’re using the golangci-lint GitHub Action, you might expect Dependabot to automatically update us when new versions are released. In practice, that hasn’t been happening—otherwise we would already be up to date.

i would also try to only run this once a day, once an hour seems a bit much if we do go forward with it

Regarding the schedule: running this workflow once per hour might seem frequent, but it doesn’t cost us anything. The benefit of checking hourly is that we avoid situations like #754, where we fell behind on updates. If a new release issue is created, we can treat it as a priority before merging other PRs that day.

Also worth noting: the workflow will only ever create one issue per release, so the frequency of the cron job won’t result in duplicates.

I’m in favor of having a dedicated workflow for this and running it hourly, but I’m open to other suggestions if the team feels differently.

[anthony-gomez-fastly]

if we want to use the latest version of golangci-lint we can just set the action version to latest as well

*this still means we have to manage our own local versions, but we were doing that anyway

[philippschulte]

if we want to use the latest version of golangci-lint we can just set the action version to latest as well

sure that works but I am not a fan of @latest and to have to search the build logs for the version we use in CI. With this workflow everybody is in the loop and can update their local instance accordingly. There is no cost to this change but it is preference. No matter what we need to address this issue either way!

@kpfleming please weigh in on this and make a decision how we want to move forward. Thanks

[anthony-gomez-fastly]

we could also add go install github.com/golangci/golangci-lint/cmd/golangci-lint@latest to the makefile which should at least make it so that everyone is on the latest all the time locally

[philippschulte]

@anthony-gomez-fastly yes, that's a good idea with the makefile! I haven't thought about that! I think this is a good plan to move forward instead of adding a new pr and manually bumping all repos every time a new release is out. And not to forget to keep the local instance in sync.

[kpfleming]

Dependabot can't handle this for us because the golangci-lint Action has a separate versioning scheme from golangci-lint itself; the Action is currently at version 8.0.0 while the tool is at version 2.4.0. Dependabot will tell us about new versions of the Action, but not new versions of the tool.

The only way that Dependabot could tell us about new versions of the tool would be for it to be listed in go.mod or a similar file, but we've already determined that we don't want to do that.

I think the best course of action may be to pin the version of golangci-lint in every place that we use it (including in Makefile so that local builds use the same version), but add an additional job in the Actions workflow which allows the Action to use the latest version. That job's status would not be required for a PR to be mergeable, it would just be informational, but it would mean that every PR would be tested against both the pinned and latest versions and if a new release of golangci-lint starts causing failures we'll see them the next time a PR's Actions workflows are run. We can then decide when/how we want to address the failures in a separate PR which also changes the pinned version to the new version.

[philippschulte]

I'll close this one out in favor of #757.