Another, even better instalment of enhanced build triggers is now available as GA. This time, the focus is on pull requests.
What’s new:
Granular trigger control
No more one-size-fits-all triggers. Our enhanced system allows you to define intricate patterns for:
| Control | Description |
|---|---|
pull_request_comment |
Trigger a one-off build based on comments posted on a PR |
commit_message |
Trigger builds based on specific commit messages in pushes to a PR |
changed_files |
Trigger builds when specific files are modified in a PR. |
Some handy examples
- Pull request comments: Think manual triggering of specific tests. Add a specific keyword (e.g.,
run-tests) to a pull request comment and trigger specific pipelines. This offers flexibility for scenarios where pre-defined commit message or label triggers might not be suitable. - Commit messages: Trigger builds based on specific keywords within commit messages, like “hotfix:” for hotfix commits or “feat:” for feature development
- Changed files: Trigger builds only when changes occur within designated file paths, such as
.swiftfiles within theiosdirectory, ideal for isolating builds for targeted updates. This is especially useful for monorepos.
These controls allow you to tailor build execution precisely based on the nature of changes within a pull request.
Combined trigger strategies: Craft workflows with precision
Imagine the possibilities. Combine these new triggers to create sophisticated build configurations perfectly tailored to your needs. Here are just a few examples:
- Targeted builds only for commits on a PR on feature branches that also involve changes within specific files or directories…
- Focussed manual triggering of builds on specific file changes to a PR on a specific target branch, only after a comment is added.
Regex Configuration: the power of patterns
The new trigger controls continue using the power of REGEX for flexible config.
- Matching branches containing version numbers or specific strings.
- Excluding specific branches from triggering builds.
- Identifying pull requests with labels matching a pattern or a combination of labels.
- Targeting commits that fix bugs or add features based on keywords in the message.
What’s the benefit:
These advancements translate to a development process with:
- Reduced build noise: Trigger builds only when truly necessary, saving valuable resources.
- Improved efficiency: Streamline your workflow by automating builds based on specific criteria.
- Enhanced accuracy: Focus builds on targeted changes, ensuring accurate testing and feedback.
Get started and explore!
We invite you to delve deeper! Explore how to leverage these features to create highly customized workflows that perfectly align with your development process. Stay tuned for further resources and tutorials to help you unlock the full potential of enhanced build triggers.
Give us feedback on this thread!