PR deployment fails often due to mergability check

[nguyentvan7]

We are using pull_request_target action trigger so forks can have secret permission. Compared to the default pull_request action trigger, pull_request_target does not wait for the mergability check to complete before triggering the action.

This means the merge commit is commonly not created by the time we start the action, and so the action will actually run on an old commit, compared to the head of the PR.

From how I understand it, adding a sleep/delay to the action will not fix it, as once the action starts, all the local variables, such as the merge commit reference, are locked in and unchangeable.

actions/checkout#518 (comment)

[nguyentvan7]

We could resolve this by fetching the merge commit via rest API during the action

However this is unsafe, as the commit the action was approved on could be different than what is fetched, if a malicious actor did something between the safe commit and us fetching the merge commit.

There is probably some way to validate the merge commit we fetched matches the head of the PR at the time of running the action