CI: make lint failure at PR checks if there are any issues

[Warashi]

What would you like to be added:

make lint failure at PR checks if there are any issues

Why is this needed:

This check is passed because the line issued is not the changed line in the PR.
https://github.com/pipe-cd/pipecd/actions/runs/23285781519/job/67708809150#step:3:117

However, gofmt linter seems reporting all issues as the first line.
So this check cannot catch such error in the PR checks.

If we merge such a PR without resolving the issues, the CI with the master branch will fail.

[majiayu000]

Hi, I've been looking into this and traced the root cause.

Proposed approach: Modify the GitHub Actions lint workflow to change the reviewdog filter_mode (or equivalent golangci-lint new-from-rev setting) so that gofmt issues are reported even when the affected line is not in the PR diff. Likely a one-line change in .github/workflows/ lint config — e.g., changing filter_mode from 'file' or 'diff_context' to 'nofilter' for the gofmt linter, or adjusting golangci-lint's --new-from-rev flag.

I'll open a draft PR shortly. Happy to adjust based on your preference.

[Warashi]

@majiayu000
Thank you for suggestion!
Your idea sounds good for me, so please open a draft PR and send review-request to me?
I want to check the behavior on it and discuss.

[majiayu000]

I reproduced the root cause and confirmed this issue.

• In run 23285781519 (go (./pkg/app/pipedv1/plugin/kubernetes_multicluster)), golangci-lint reported a gofmt error, but reviewdog was running with filter_mode=added, so the PR check did not fail.
• This matches the behavior where gofmt findings can be skipped in PR checks depending on diff filtering.

I updated PR #6622 accordingly:

• set filter_mode: nofilter in .github/workflows/lint.yaml
• fixed the newly surfaced lint findings in kubernetes_multicluster (config/application.go, deployment/canary_test.go, deployment/baseline_test.go)

I also replayed the module lint locally with golangci-lint v2.4.0 on the latest PR head and it now returns 0 issues for that module.

Could you please take a look and (if needed) re-run/approve the workflow checks on #6622?