potiuk edited a comment on pull request #11656:
URL: https://github.com/apache/airflow/pull/11656#issuecomment-712005444
@ashb @kaxil -> I solved it by rather straightforward approach.
* In the "Build" workflow I take as base the "targetCommitSha" -> I already
implemented in the "cancel-workflow-run" the logic to pick the right commit
depending on whether merge commit is done by GitHub or not
* In the "CI Build" workflow I take as base the "${ github.sha }" which is
also good and it's either the merge commit (if there is one) or the source
commit (if there is no merge commit - which is the case when there is only one
commit in PR and the PR is based on the current master).
In both cases I check which files has changed by generating list of changes
in the commit vs. it's first parent (^). For that I fetch the commit I want
with 'fetch-depth' set to 2. So this is also rather fast and optimal - without
fetching the whole history.
This seems to work perfectly well. Seems that in GitHub even in case of
Merge Commit the first parent is the "target branch". It could be the other
way, but seems that in GitHub it is always this direction. And in any case it
does not matter because if you have a single merge commit generated from
sequence of commits and merged to master, no matter which side you compare,
comparing with either parents should show you the same files.
----------------------------------------------------------------
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]
