2.1.2.2. Running Builds/Tests on Pull Requests & Merges
2.1.2.2. Running Builds/Tests on Pull Requests & Merges
Catching bugs before code merges to the main branch prevents broken builds from blocking the entire team. The pattern: every pull request triggers a build-and-test cycle, and the PR can't be merged until tests pass.
With CodeCommit: Configure an EventBridge rule that matches pullRequestCreated and pullRequestSourceBranchUpdated events. The rule triggers a CodeBuild project that checks out the PR branch, runs tests, and posts the result back as a PR comment via the CodeCommit API.
With GitHub/Bitbucket: CodePipeline V2 supports triggers on pull request events via CodeConnections. Alternatively, use GitHub Actions or Bitbucket Pipelines to call CodeBuild directly via the aws codebuild start-build API.
Build Badge pattern: CodeBuild generates a badge URL that shows pass/fail status. Embed this in your repository README to give the team instant visibility into build health. Enable it in the CodeBuild project settings.
Merge gating: Combine CodeCommit approval rules (require N approvals + successful build) or GitHub branch protection rules (require status checks to pass) to enforce quality gates. A common pattern requires:
- At least one peer approval
- All CI tests passing
- No merge conflicts with the target branch
Exam Trap: CodePipeline V1 doesn't support PR-based triggers ā it only triggers on pushes to a configured branch. If the exam asks about running tests on pull requests, the answer involves EventBridge + CodeBuild directly (not CodePipeline), unless the scenario specifies Pipeline V2.
š” Tip: Run a lighter test suite on PR builds (unit + lint) and the full suite on merge to main. This keeps PR feedback under 5 minutes while maintaining thorough validation on the main branch.
