CI not triggered after workflow is manually triggered

[jpkrohling]

During the release of v0.120.0, I noticed that, on the first PR, the "Build" workflow was marked as "starting" but never actually started. I had to close the PR and open it again. I thought it was a fluke, but the same thing happened when I opened a new PR with contrib at v0.120.1. Closing and opening the PR did the trick once again.

Apparently, @bogdandrutu has the same thing happen to him, judging by the similar PR for v0.119.0, and the same behavior goes back to even v0.117.0. Apparently, we had it working for v0.116.0.

References:

• v0.120.0 (take 2): [chore] Prepare release 0.120.0 #832
• v0.120.0 (take 1): [chore] Prepare release 0.120.0 #830
• v0.119.0: [chore] Prepare release 0.119.0 #811
• v0.118.0: [chore] Prepare release 0.118.0 #802
• v0.117.0: [chore] Prepare release 0.117.0 #793
• v0.116.0: [chore] Prepare release v0.116.0 #780

[mowies]

I think this happens because the PR and all the github actions trigger events are done by the built-in github token and according to the docs, things triggered by the workflow-default github token are not run to prevent recursive cascades.

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.

source

[mowies]

This is also one of the list purposed of the otelbot, maybe we could use that one to fix this issue.
https://github.com/open-telemetry/community/blob/main/assets.md#otelbot