Question
Is it possible to implement the following requirements in TeamCity?
- The source code is in a GitHub monorepo.
- It has a protected branch that requires multiple Status Checks.
- A Pull Request modifies only specific project(s) within the monorepo, triggering the build.
- TeamCity should build the changed projects and publish successful status checks for the whole chain without needlessly rerunning builds for unchanged projects.
Answer
Verified on: 2025.11.2
The recommended approach is to use GitHub Checks' native support via the GitHub Checks Webhook Trigger in a composite build configuration.
- Create a composite build configuration.
- Add a GitHub Checks Webhook Trigger to this composite configuration.
- Attach the monorepo VCS root to the composite configuration.
- Add Snapshot Dependencies from the composite configuration to your project build configurations (the builds that compile/test the relevant parts of the monorepo). Ensure the "Do not run new build if there is a suitable one" and "Only use successful builds from suitable ones" options are enabled.
- In the individual project build configurations, configure Checkout Rules to include only the relevant directories (or exclude the irrelevant ones).
This setup will publish a single status check to GitHub, aggregating all builds and test results from the upstream. If need be, you can create multiple composite builds with a GitHub Checks Webhook Trigger, one for each part of the build chain you want a separate check for.
How it works: The composite build is triggered every time GitHub emits the check_suite event and will publish the status information, but the actual dependency of the composite build might be skipped (due to Checkout Rules) if no relevant files were changed in that PR.
Additional information
- Pull Requests Build Feature: The GitHub Checks Webhook Trigger can build pull requests, but it does not yet support the Pull Requests build feature (see "GitHub Checks Webhook Trigger" doesn't work in the case of tags instead of branches and with Pull Requests Build feature). The build will be labeled with the source branch name, and PR details will appear on the build overview page, but the source branch of the PR must be included in the VCS root's Branch Specification.
- Duplicate Builds: Consider removing standard VCS triggers from the build chain or adjusting their settings. Leaving them enabled alongside the GitHub Checks Webhook Trigger can produce duplicate builds (depending on the trigger settings). If required, enable the "Trigger only on Pull Requests" option in the GitHub Checks Webhook Trigger settings. See more information in the GitHub Checks Webhook Trigger documentation.
Comments
0 comments
Please sign in to leave a comment.