open-telemetry
Renovate Bot can't handle multi-step Golang tidy
As seen in many PRs like #1440, Renovate is not able to cleanly handle the multi-step build process we need in otel-arrow when updating Go modules.
Not only do we need to update in go/ subdirectory, but oftentimes we need to execute Golang collector builder with make genotelarrowcol for dependency upgrades to reflect in collector/cmd/otelarrowcol.
While looking through the main Collector repo, I came across this workflow used for tidying up after Renovate PRs using the otelbot identity (which we already use for Release processes, see #737).
We can try to copy this and hopefully solve our problems with painful Golang updates requiring manual touches.
For a look at this process in action, check out opentelemetry-collector #14181.
Not fully working - additional workflows don't run after commit. Troubleshooting...
Now the otelbot app token usage returns 403: https://github.com/open-telemetry/otel-arrow/actions/runs/19586179885/job/56095437615?pr=1458
Will be following up on this with @trask - seeing if this app token doesn't have the right permissions.
Curiously it seems the Collector repo implementation doesn't use the special app token and it works, but in my experience PR workflows don't run when you push with that default token.
This is still a non-blocking issue for other development work in the repo, so it is fine to be in this state for a few days.
the standard otelbot doesn't have write access to any repos
we can create a SIG-specific otelbot if you need more permissions
in this case though, you should be able to use the default token ${{ secrets.GITHUB_TOKEN }}, which is essentially what that collector workflow is using (because it doesn't have persist-credentials: false on the checkout).
in my experience PR workflows don't run when you push with that default token
this is the case when using the pull_request trigger, but these workflows are using pull_request_target, which comes with more permissions (and more dangers)
I think it's ok in this case because the branch you're checkout out and running against is not in a fork, and so anyone who can update that branch already has write permission to the repo
@trask that explanation does seem to match the initial behavior I observed in the Collector repository, but it appears to contradict the GitHub docs about Triggering a workflow.
Upon closer review of a few different PRs in the Collector repo, it appears the maintainers may be getting around this limitation by closing and re-opening the PR or updating branch from main. I suppose these actions 'reset' the last touch point of the PR, allowing workflow behavior to run again.
I will give this another attempt and see if this is too clunky of a workaround.
oh, right, this is a great reason to use a repo-specific otelbot 👍
just let me know and I'll set one up for arrow
Closing/re-opening the PR did work in the interim for #1463 and #1466. Opening a sub-issue to follow up about repo-specific bot.
Upon closer review of a few different PRs in the Collector repo, it appears the maintainers may be getting around this limitation by https://github.com/open-telemetry/opentelemetry-collector/pull/14181 or https://github.com/open-telemetry/opentelemetry-collector/pull/14145.
@open-telemetry/collector-maintainers just open a community issue if you'd like a repo-specific otelbot too