Description
Right now, we have 2 events that trigger our workflows: push and pull_request.
While working on the 1.27 release I noticed that our 2 release PRs where running duplicated jobs, for both the push and pull_request triggers. The trigger name shows up in the checks box in the PR, inside parentheses, somehting like this:
Test 0 / opentelemetry-exporter-otlp-proto-common-1 3.12 Windows (pull_request)
For any other non-release PRs, I noticed that the push trigger does not trigger any jobs, since no job has push as its trigger.
Now, for this release we are introducing for the first time the generate-workflows job. This job checks that the workflow files are up to date with any changes that may have happened in tox.ini which is the source of information for our workflow files.
To check this, this job runs tox -e generate-workflows which parses the tox.ini file, and then uses Jinja2 templates to generate the workflow files. In the templates we define the values for the environment variables CORE_REPO_SHA/CONTRIB_REPO_SHA to be always main, since that is what we always want except for a few cases, release PRs being one of them because we want to set the value for those environment variables to be a specific commit.
The generate-workflows will fail if CORE_REPO_SHA/CONTRIB_REPO_SHA is set to something else than main so we want to skip that job for release PRs. We skip this job in the exact same way we skip the changelog job for PRs that do not require an update to CHANGELOG.md, by using a PR label. In this case, the label is Skip generate-workflows.
Here is the code that skips this job if Skip generate-workflows label is set:
if: |
!contains(github.event.pull_request.labels.*.name, 'Skip generate-workflows')
&& github.actor != 'opentelemetrybot'
Now, this code only works for jobs that were triggered by pull_request, the generate-workflows job with the push trigger still gets executed, fails and that blocks the release PR, causing this issue.
I believe the condition above does not