Historically, CircleCI users have been limited to setting up validation systems that only worked within the scope of a single repository:
If a pipeline’s YML config was stored in Repo A, that pipeline could only be triggered from events on Repo A (or from a Custom Webhook). This has left many customers unable to set up the validation system that they desire.
We have launched additional enhancements to pipeline and trigger configuration, which will enable customers to build any validation setup that they need.
Changes to Pipeline configuration in Project Settings of the CircleCI UI:
- The field “Fallback branch” has been removed. This field was previously used to determine which branch should be used to fetch config on a Custom Webhook
- A new field, “Checkout source”, has been added. This field lets users configure which repository should be checked out when a checkout step is executed
Changes to Trigger configuration in Project Settings of the CircleCI UI:
- A new field “Config branch” has been added. This field is only displayed if the “config source” of the associated pipeline is different from the trigger repo. It lets users specify from which branch the YML configuration file should be fetched from when an event is received
- A new field “Checkout branch” has been added. This field is only displayed if the “Checkout source” of the associated pipeline is different from the trigger repo. It lets users specify which branch should be checked out when a checkout step is executed
These seemingly small changes enable users to achieve immense flexibility for automating work on CircleCI. A simple way to think about it is that CircleCI can now:
- Trigger a pipeline from Repo A
- Fetch config from repo B
- Checkout code and tests from repo C
Notably, this enables support for two highly requested use cases:
- Centralized config management (e.g. storing all pipeline configurations in a single repository maintained by the platform team, and/or using the same config file for different pipelines)
- Sharing of tests across repositories (e.g. triggering a set of integration tests that live in a single repository after automated deploys of any repository)
These changes are live for all GitHub customers (including orgs that integrate with CircleCI’s GitHub OAuth App) who use CircleCI Cloud, read the docs for how to get started.