pr workflow - use merge SHA when available#17
Conversation
|
@briantist thanks a lot for figuring this out! |
|
I am beginning to worry that there may be a problem with this.. I noticed in a previous PR, and now in a new one, that the docs build is always 1 push behind, somehow. In this PR: ansible-collections/community.hashi_vault#223 I made my second push, which contained both of these commits (in this order): The docs build ran and failed: https://github.com/ansible-collections/community.hashi_vault/runs/5401472234?check_suite_focus=true The HEAD checkout it did was using the merge_commit_sha, The build failed because the lookup plugin contained a reference to the module; this problem existed in my first push. It was fixed in the second, but is building as though it wasn't. If I look directly at that commit, it looks like my first push, wherein the module was missing: I don't have time to dig into it further now, but it looks a lot like this: |
Related to:
The changes in #14 result in a failed build when the PR is closed/merged, because the special merge "branch" doesn't exist anymore.
However, I have found that
github.event.pull_request.merge_commit_shadoes exist on closed/merged/reopened PRs. It does not exist on the first opened event though (whereas the merge branch does).I also did some tests showing that when both the merge SHA and the merge branch exist, the content of their checkouts are exactly the same: https://github.com/briantist/gha-junk/runs/4827842600?check_suite_focus=true
This PR sets an output var for the ref we'll be using in the PR checkout. We start with the SHA because that will either be set, or blank. If the SHA is blank, then we fall back to the merge "branch".
I believe this will cover all bases.