Experiment 3

You should set up the required code repositories in 13.2 Prepare Source Code if you have not done it yet.

In this section, you are going to begin by securing your main branch with the Require branches to be up to date before merging rule. Next, you create a pull request for person a’s code changes, followed by a separate one for person b’s. After both pull requests are submitted, you wait for the CI workflows to complete. Since person a’s changes have not been merged into main branch yet, person b’s CI check passes successfully without including person a’s updates. Confidently, you merge person a’s pull request into the main branch. With the new branch protection rule in place, person b’s pull request then triggers an “update required” notification immediately. At this point, you manually update the person-b branch, which then invokes a new CI workflow run that tests person b’s changes now integrated with person a’s updates in the main branch. This time, your CI workflow execution should fail again.

1. On the remote repository,

• Select Settings tab.
• Select Branches on the left sidebar.
• Click Add branch ruleset.

2. On the ruleset settings page,

• For Ruleset Name, enter main-protection.
• For Enforcement status, select Active.

3. In the Target branches section,

• Click Add target dropdown.
• Choose Include default branch. Your default branch should be main branch.

4.

• Enable Require status checks to pass.
• Enable Require branches to be up to date before merging.
• Enable Do not require status checks on creation.
• Click the Add checks dropdown.
• Filter with run-test value.
• Select Add run-test.

5. Scroll down to the bottom, click Create.

6. Make sure you are still in the right project folder.

cd path/to/experiment-3

7. Switch to person-a branch.

git checkout person-a

8. Push your changes to the remote repository on the corresponding branch.

git push --set-upstream origin person-a

9. On your remote repository, click Compare & pull request.

10. Click Create pull request.

11. On your local repository, switch to person-b branch.

git checkout person-b

12. Push your changes to the remote repository on the corresponding branch.

git push --set-upstream origin person-b

13. On your remote repository, click Compare & pull request.

14. Click Create pull request.

15. You should now have passed CI workflow executions of both pull requests. Do not click Merge pull request yet.

• Console for the person a’s pull request.

• Console for the person b’s pull request.

16. On the person a’s pull request console, click Merge pull request.

17. Click Confirm merge.

18. Click Delete branch.

19. At the time you click the Confirm merge button on the person a’s pull request in step 17, you should now see the This branch is out-of-date with the base branch notification immediately on the person b’s pull request console. Before you manually update the branch, click Details to review the logs from the previous CI check.

20. Click the Show main.py content step dropdown, you might notice that the default value of n should still be DEFAULT since the person b did not change it.

21. Back to the person b’s pull request console, click Update branch to synchronize the person b’s pull request with the main branch.

22. Another CI workflow execution should be triggered.

Wait for seconds, you should see that the CI check has failed.

23. Click Details to show the job’s logs.

24. Expand the Shown main.py content step dropdown, you might now notice that default value of n has turned into 7. This means that GitHub Actions Checkout now pulls in person b’s code changes, fully integrated with the latest updates from the main branch. As a result, the CI check should fail.

In this experiment, you see that the Require branches to be up to date before merging rule forces the person-b branch to be manually synced with the main branch before merging.

Though your main branch is now protected, this can lead to a scenario where one merge blocks others. For instance, imagine 100 pull requests, all with passing CI checks, ready to be merged into the main branch. If one pull request merges first, the others will have to be updated manually. Additionally, any updated pull request could fail later when rerun against the newly updated main branch and need to be resolved. In the worst case, a single pull request might have to wait for 99 others to merge first before it can be integrated.

To handle with this issue at scale, you might want to leverage GitHub Actions Merge Group. Let’s dive into the final experiment!