should the CI check only apply to modified files? Seems odd to have to update files just for this.

I agree. We should use this option.

Ideally we should run only goheader on new files, since an upgrade to golangci-lint might find other lint errors in non-new files. I've created golangci/golangci-lint-action#1140 for this.

In the meantime, let's set only-new-issues: true in our golangci-lint action configuration (pushed on this branch).

PS: side thing I found, added in #88: Use golangci-lint's option new-from-rev: HEAD where HEAD is set automatically to the base fork commit - that only checks diffs on changed files compared to that commit, pretty cool.

MOD-YEAR-RANGE doesn't seem to play nice when it's not actually a range.

It works fine for me, it fails with error Pattern ((20\d\d\-2025)|(2025)) doesn't match which makes sense. However, since we would ideally like to keep unmodified files to their last modified year, this is problematic (last modified should stay in 2024 or 20xx-2024). The Ci does the trick by only running on modified and new files, but running golangci-lint run locally would fail on old and not-modified files. To go around this, I decided to disable goheader locally and enable it only in the CI... deal??

Obviously the perfect solution would be a linter handling the git plumbing to find only changed files and scan headers for only those files, one can only dream 🤷 Unless it exists let me know!

@ARR4N Whoops I think that got auto-merged on your approval, I did #101 with your suggestions 👍

PS: we should be careful about approving & auto-merge enabled.
I used auto-merge because playing cat-and-mouse between keeping the branch up to date, waiting for Ci to complete and re-asking for approvals... is not too fun 🤷 Although after seeing this, perhaps we should disable auto-merge? The best thing to do in my view is to disable the requirement to be based on the last commit of the default branch, but to each their opinion 😄