Pull Requests Deployed From Custom Merge Commits aren't reflected in Web UI

Our web game server tooling allows us to merge and deploy open pull requests into production. We’re working on adding support for GitHub deployments so as to increase visibility of what’s being tested in the repo-space.

To facilitate this, one or more pull request heads are merged into the master branch. The resulting SHA is pushed in a temporary branch to make the server’s operating commit visible in the Web UI before being built.

While adding deployment support I noticed that the deployment status at the bottom of PRs only seems to appear if you deploy the exact HEAD SHA of said PR. Deploying a commit that has the PR’s HEAD as a parent doesn’t seem to provide the UI notification despite the fact that the merge SHA was deployed.

As a result, it seems that only one pull request may be deployed to an environment at a time. I assume it’s possible to fudge the results by creating a separate deployment per PR, but this would not be ideal as it would involve tracking many more deployments per build. It also makes the actual merge-path used untraceable based on what the API/WebUI says. Would it be possible for the UI to update if any commit that is a child of the PR head is deployed?

3 Likes

To clarify how the git side of the test merge process works. The server tracks the master branch, hard resetting it to the origin version on clean updates. When a PR is to be test merged, pull/<Number>/headrefs/heads is fetched from origin into a temporary branch in the server’s local repository. This branch is then merged into the server’s local master branch before being built.