golangci-lint GitHub action is sometimes not triggered on PRs opened by dependabot

[sbueringer]

What steps did you take and what happened?

Sometimes when dependabot opens new bump PRs the golangci-lint GitHub action is not triggered

The PR is then stuck and can't be merged because it's waiting for "lint"

What did you expect to happen?

Action should be triggered as usual

Cluster API version

main

Kubernetes version

Anything else you would like to add?

Workaround is to manually edit the PR description. Potentially also works to edit the PR title but I didn't try that yet

Label(s) to be applied

/kind bug
One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[sbueringer]

/triage accepted

[killianmuldoon]

I wonder if this is down to our dependabot action somehow - that's the main diff IMO between these PRs and the ones we create manually.

This is the current action: https://github.com/kubernetes-sigs/cluster-api/blob/main/.github/workflows/pr-dependabot.yaml

It checks out the code, runs make generate and then commits the result. I don't have any idea how that could be impacting the lint action right now, but it's a first place to look.

[sbueringer]

Maybe somehow. We should try to gather more data, e.g. under which circumstances it exactly happens (e.g. is the pr-dependabot action pushing changes in these cases)

[killianmuldoon]

I did a bit of digging and it looks like we only have this problem on PRs which have 2 commits i.e. those that ran the github action and made an additional change. Most recently: #9564

[killianmuldoon]

Okay - I think I found the root cause for this. When using the repo's own repository taken workflows aren't triggered:

When you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN, with the exception of workflow_dispatch and repository_dispatch, will not create a new workflow run. This prevents you from accidentally creating recursive workflow runs. For example, if a workflow run pushes code using the repository's GITHUB_TOKEN, a new workflow will not run even when the repository contains a workflow configured to run when push events occur.

The pr-dependabot action uses EndBug/add-and-commit to commit the generated code which warns specifically about this issue.

That's because you're checking out the repo using the built-in GITHUB_TOKEN secret: GitHub sees that the push event has been triggered by a commit generated by CI, and doesn't run any further checks to avoid unintentional check loops.

The advice is to use a Personal Access Token in the action, which I don't think we want to do. I'm not sure what the best solution to this is right now, but it's working as intended from the GitHub side.

I have the subjective feeling that this is happening more often, but I'm not sure that's right. Maybe changing the schedule for dependabot PRs to happen on different days results in more generated commits?

[killianmuldoon]

Only curious as to why this doesn't seem to happen in the same way on the controller-runtime repo: e.g. kubernetes-sigs/controller-runtime#2521

[fabriziopandini]

/kind flake
(not really a test flake but probably the best fit)
/priority important-long-term