Unexpected (wrong?) commit is used by GitHub Actions when building/rendering documents on a PR #389
Description
When the build workflow is triggered on a PR, the document repo is checked out on the runner. However, GitHub merges the branch referenced by the PR before the jobs/steps specified in the action take place. Therefore, what gets rendered (and used in creating redlines etc) is the result of (temporarily) merging the PR rather than the head of the branch referenced by the PR.
This surprising GitHub behaviour is discussed in https://github.com/orgs/community/discussions/26325
Normally for SMTPE document workflows this won't make a difference e.g. there is only one branch open at a time and changes are not made directly to main.
However, to avoid confusion it would presumably be best to use the commit at the head of the branch rather than the merge commit when carrying out rendering etc? Any redline generated would then align with the "Files changed" diff view on the PR, and any document rendering would be the same as when carried out locally on the author's machine.
Regardless, one aspect that should be reviewed is where commitHash is used in build.mjs -- not least, in:
- creating log messages
- creating the S3 path to which a copy of rendered docs etc are uploaded
The value of commitHash will (in the scenario described above) actually contain the commit hash for an orphaned merge commit and so isn't a value that's useful to anyone (i.e. it's not a commit that appears in the history of any branch).