Powerful build automation: A deep dive into Bitrise's new enhanced build triggers

Irrelevant code changes triggering unnecessary builds? Ensure that every build is deliberate, intended, and relevant with our enhanced build triggers. Our range of new advanced trigger controls allows you to kick off builds with precision. Dive into how you can leverage these powerful capabilities and benefit from a more targeted approach to automation.

What’s new

Introducing powerful new trigger controls for your main Git events.

PUSH

PR

These new controls can be leveraged via the “Triggers” tab on the workflow editor.

Alternatively, if you prefer using YAML, you can easily add these new controls to your trigger map. Follow the guide here.

Surgical precision in your DevOps processes

Build triggers act as the conductors in your software delivery pipeline. They function as the bridge between external events and your meticulously crafted Bitrise workflows. When these pre-defined events occur, such as a pull request being created or specific code changes being pushed, the triggers activate the corresponding workflow, initiating the automated processes you've established.

While traditional build triggers based on branch names were a good foundation, the new controls provide developers with surgical precision over what build should initiate on Bitrise based on the nature and context of their Git event. Imagine the wasted resources and time spent on unnecessary builds triggered by irrelevant code changes.

You can now target specific commits, pinpoint file changes in monorepos, and even include pull request labels and comments into your automation. The main capabilities introduced via this change are:

• Granular triggers controls: Define patterns (using regular expressions or wildcards) to match specific commit messages, file path changes, pull request labels, or pull request comments. This allows you to tailor build execution precisely based on the nature of changes within a push or a pull request.
• Combined trigger strategies: Craft intricate configurations by combining these new triggers. Imagine triggering builds only for pull requests targeting a specific branch with a designated label, or focusing builds on specific file changes within feature branches.
• Regex based configuration: We are now adding REGEX based configuration option for ALL triggers (existing and new). By harnessing the flexibility of regular expressions, you can define intricate patterns for various triggers: match branches containing a version number or string, Exclude specific branches from triggering builds, pull requests with specific labels matching a pattern or a combination of labels, commits that fix a bug or add a feature, etc.

Real-world use cases to help you leverage the new controls

Push triggers: Tailoring builds to specific commits or location of changes

Blanket builds for every push is not ideal for everyone. With Bitrise's enhanced push triggers, you can define granular patterns to target specific commit messages or focus on where the changes are targeted within a mono repo.

1. Push: commit_message
   1. Feature branch builds:
      • Trigger builds only for commits with messages that start with "feat" potentially followed by details about the feature.
      • Say, your commit message looks like this: feat(new login page): create login controller. You can use a wild card pattern like feat* or a regex pattern such as this: feat\(.+\):.* to trigger builds for such commit messages.
      • This ensures builds only run for feature development and avoids unnecessary builds for bug fixes or documentation updates.
   2. Hotfix builds with severity levels:
      • Initiate builds specifically for hotfix commits classified as critical or high severity.
      • Say, your commit message looks like this: hotfix critical: Resolved security vulnerability in user authentication. You can use a wild card pattern like hotfix.* or a regex pattern like hotfix\s*(critical|high):.* to trigger builds for such commit messages.
   3. Enforcing code style:
      • Initiate checks for commits that enforce a code style.
      • Say, your commit message looks like this: fix(style): update linting rules . You can use a wild card pattern like fix(style)* or a regex pattern like fix\(\s*style\s*\):\s+.* to trigger builds that runs a linter or code formatter.

2. Push: changed_files
   1. Targeted changes in mono repo:
      • Trigger builds only when changes occur in specific directories and their subdirectories of your monorepo. This helps isolate testing efforts for specific components within the larger codebase and significantly reduces unnecessary builds for changes in other parts of the codebase.
      • A regex pattern like ios/.*\.swift$ can trigger builds when only Swift files within the iOS directory are changed inside the monorepo. Similarly, simple wild card patterns like ios/app.js or ios/components/MyView.swift or ios/layouts/main_screen.xml can target specific files in the relevant directories and trigger builds.
      • A regex pattern like src/ui/.* can trigger builds for UI component updates by targeting changes in the "ui" directory or specific subdirectories within it. This helps target builds focused on UI changes.
      • A regex pattern like src/(components|services)/.*\.js$ would initiate builds only when JavaScript files within the components or services directories (and their subdirectories) are modified.
      • A regex pattern like backend/services/.*\.go$ triggers builds only when changes occur in Go files within the "backend/services" directory or any of its subdirectories.
   2. Ignoring certain files: Exclude irrelevant files (e.g., configuration files) by negating a pattern. To skip builds when only the .gitignore file is changed, use a regex pattern like ^(?!\.gitignore).* .
   3. Ignore generated files: Exclude automatically generated files (e.g., compiled code) by using a negated pattern. For instance, ^(?!build).+\/.*\.js$ would trigger builds on all JavaScript file changes except those within the build directory (assuming generated code resides there).

PR triggers: Initiate builds based on PR labels (review readiness, build testing, deployment), comments (manual test triggers, retests), and targeting specific changes or commit messages within a PR

1. pull_request_label
   1. Initiate builds based on review readiness: Manually trigger builds for specific PRs by adding a label like ready-for-review.
   2. Manual build initiation: Manually trigger builds for specific PRs by adding a label like build-test. This provides flexibility and control over when builds run for PRs.
   3. Automated testing: Configure builds to be triggered automatically when a test label is added to a PR. This enables a seamless integration between code review and automated testing.
   4. Deployment pipelines: Set up a PR label like deploy-to-staging to initiate deployment pipelines upon code review approval (assuming the label is added after successful review). This streamlines the deployment process for approved PRs.

2. pull_request_comment
   1. 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.
   2. Manual triggering of a retest: A triggered build might fail due to a flaky environment. You can now add a comment to re-run the build if the flaky environment issue has been fixed.

3. PR: changed_files (similar use cases as PUSH)
   1. Targeted changes in mono repo: For mono repos, trigger builds only when a PR targets changex occurng in specific directories and their subdirectories. This helps isolate testing efforts for specific components within the larger codebase. For example, a pattern like src/(components|services)/.*\.js$ would initiate builds only when a PR affects JavaScript files within the components or services directories (and their subdirectories) are modified. This significantly reduces unnecessary builds for changes in other parts of the codebase.
   2. UI component updates: Trigger builds for UI component updates by targeting PRs that affect the the "ui" directory or specific subdirectories within it.

4. PR: commit_messages (similar use cases as PUSH)
   1. Feature branch builds: Trigger builds only for commits to a PR containing messages that start with "feat" (e.g., "feat(auth): implement login flow"). This ensures builds only run for feature development and avoids unnecessary builds for bug fixes or documentation updates.
   2. Hotfix builds with severity levels: Define a regex pattern like hotfix.* or hotfix\s*(critical|high):.* to initiate builds specifically for hotfix commits classified as critical or high severity. This prioritizes builds for urgent fixes.
   3. Enforcing code style: Enforce consistent code style by requiring a commit message like "fix(style): update linting rules" before triggering a build that runs a linter or code formatter.

New YAML syntax

To complement the granular controls and regex enhancements, Bitrise is introducing upgrades to the YAML syntax for trigger configuration. This provides a clear and well-structured way to define your triggers. Descriptive field names and a dedicated field for regular expressions enhance readability, making it easier to manage complex trigger configurations without relying on the UI.

Check out our Devcenter guide to understand these better. Below are some YAML examples for inspiration.

Example 1: push trigger targeting a commit message and a directory

# PUSH TRIGGER EXAMPLE: 

type: code-push
  push_branch: '*'
  commit_message: "ci"
  changed_files: "ios/*"
  workflow: test
  enabled: true

The above trigger map triggers the "test" workflow when

• A push with a commit message “ci” is made AND
• Any files within the “ios” directory and subdirectories are affected.

Example 2: PR trigger targeting source and target branches along with a label

# PR TRIGGER EXAMPLE:

type: pull-request
  pull_request_target_branch:
    regex: ".*"
  pull_request_source_branch: dev
  draft_pull_request_enabled: false
  pull_request_label: "ci"
  workflow: test
  enabled: false

The above trigger map triggers the "test" workflow when

• A pull request is created from the "dev" branch AND
• It has a label "ci".

Combination of conditions for precision

Example 1: Triggering builds for specific PR labels on the main branch

• Scenario: You want builds to run only when a pull request targeting the main branch has a specific label added, indicating it's ready for deployment (e.g., "deploy-to-production").
• Trigger Configuration:
  • Pull Request Label: deploy-to-production
  • Pull Request Target Branch: main
• Ensures builds are only triggered for deployment-ready pull requests, streamlining the deployment process.

Example 2: Multi-layered trigger for feature branch commits and specific file changes

• Scenario: You want builds to run only for commits on feature branches that also involve changes within specific files or directories.
• Trigger Configuration:
  • Pull Request Source Branch: Pattern matching feature branches (e.g., regex: feat\/.*  or wildcard: feat/*)
  • Commit Message: Pattern matching desired commit message content (e.g. regex: feat\(.+\):.* or wildcard feat*)
  • Changed Files: Pattern matching specific file paths or directories (e.g., regex: src/components/*.js)
• Ensures builds are only triggered for relevant changes within feature branches, focusing resources on impacted areas.

Example 3: Targeted builds for specific branch and file changes in a pull request:

• Scenario: You have a complex codebase with separate branches for different environments (e.g., "staging"). You want builds to run only when a pull request targeting the "staging" branch involves changes within specific directories.
• Trigger Configuration:
  • Pull Request Target Branch: "staging"
  • Changed Files: Pattern matching specific directories or file paths relevant to the staging environment (e.g., config/staging/**/*)
• Optimizes builds for specific environments by focusing on changes relevant to that environment.

These are just a few examples. By combining these new  triggers, you can create highly customized workflows that perfectly align with your development process. Remember to carefully craft your trigger patterns to ensure precise targeting and avoid unintended matches.

Reap the rewards: Precision powerhouse

Granular trigger controls and regex enhancements elevate your development process. Craft workflows with laser focus, triggering builds only when specific commits, file changes, PR labels or comments are met. This eliminates wasted resources on unnecessary builds, optimizes resource allocation, and minimizes disruptions with fewer failures. Embrace precision, empower your team, and unlock the efficiency that translates to faster development cycles.

Bitrise is the CI/CD Platform built for Mobile DevOps. If you’re a Bitrise user, you can use these build triggers today. Not a Bitrise user? Start for free today.