potiuk commented on a change in pull request #14996:
URL: https://github.com/apache/airflow/pull/14996#discussion_r600984082
##########
File path: .github/workflows/ci.yml
##########
@@ -504,12 +505,13 @@ ${{ hashFiles('.pre-commit-config.yaml') }}"
strategy:
matrix:
package-format: ['wheel', 'sdist']
- if: needs.build-info.outputs.image-build == 'true'
+ if: needs.build-info.outputs.image-build == 'true' &&
needs.build-info.outputs.default-branch == 'master'
Review comment:
OK. You asked this question, be prepared for the answer :). It's long,
sorry, but GitHub did NOT make it easy.
Beware. It's long even if the question is simple.
The problem is that if you are running direct push (i.e. merge to master)
you have the actual master branch in `github.ref`, indeed, however it looks
completely differently in other workflows.
When you run `pull_request` workflow, github ref is something like
`refs/pull/14996/merge`. In this case you should look for ``github.base_ref``
instead:
```
github.base_ref string The base_ref or target branch of the pull
request in a workflow run. This property is
only available when the event that triggers a workflow run is a
pull_request.
```
And - of course - it is not documented.
And ... wait for it .. base_ref is NOT set in direct pushes at all (i.e.
when you merge) so if you would like to use this information, your condition
will start looking like:
```
if github.event != 'pull_request' && github.base_ref == 'master' ||
github.ref == 'master'
```
But, unfortunately, this is just a beginning. I am not 100% sure if we are
covered here because `github.ref` behaviour for`pull_request` workflows is not
documented (many of the values in GitHub context are poorly documented or not
documented at all and I had to reverse-engineer them).
What's more - in `workflow_run` workflow you have no information whatsoever
what was the base branch (and for a change `workflow_run` for every push and
every PR runs always with `master` github.ref, no matter what is the target
branch. Not even when you query the "source_run" directly via GitHub API you
can find the base branch. This is because (surprise-surprise) when you query
the "triggering" workflow from the "triggered" one - you have no access to the
"context" of the triggering run (obviously). You only can see whatever the API
returns you and the last time when I checked there was no information about the
"base_branch" there. It could have changed since though.
So what you have to do (I did not find a better way) is that you have to
find the original PR via GitHub API and retrieve information from there. But in
order to retrieve the information from there you need to iterate through open
PRs and match the PR by branch + repo (I am already doing it to be able to push
"Status checks" to the PR. Yes. I know, it is insane. But I could not find
another way.
If you are adventurous and want to look yourself - in every job we have this
step starting from "Event " ... where I dump the context - this makes
reverse-engineering much easier (but none more pleasant).
AFAIK there is no sane way to get the 'base" branch.
That's why we have DEFAULT_BRANCH in _initialization.sh that we keep
different in every branch and I am using it. And exposing it as "output" seems
like much simpler thing to do.
I would be super happy if you could find an easier way here.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
