Ever commit code and wonder how it’s faring in the pipeline? Let's make every status update as clear as day. Every time you push new code, a series of automated CI builds and checks spring into action, each telling a part of your project's story. This is where git commit statuses come in—they transform the complex results of these processes into clear, actionable insights. Think of them as real-time signals that indicate whether your code is ready to go live or needs a little more attention. Best of all, developers can access these signals directly within the Git provider's interface. It couldn’t be easier.

Previously, Bitrise presented a single commit status based on the most recent build run. Any previous statuses on the same commit would be overwritten. Not be the best approach when managing several workflows or pipelines triggered by the same event commit. Also, it can prevent you from seeing the whole picture.

It's like trying to solve a puzzle with only one piece visible, making it impossible to grasp the entire story of your code's progress through the CI/CD pipeline or decide if any code changes need to be made.

Define your Git commit status format in YAML

New field: status_report_name

This field lets you define how each commit's status is reported using a blend of static text and dynamic variables. Whether you want a straightforward message like "Bitrise build" or a more detailed, variable-driven status such as "PR Check for <project_title>," the status_report_name field has you covered.

With the new status_report_name field, you can now configure your Git commit status to include static and dynamic components.  This way you can include context in the status report.

Dynamic values (recommended)

Dynamic commit statuses adapt to your project's specifics, offering a detailed and contextual understanding of each commit status. By using variables, you gain visibility into every workflow or pipeline triggered by a commit, ensuring no detail goes unnoticed. This is particularly important when managing multiple workflows or pipelines, as it allows you to track each one's outcome independently.

These variables adapt based on your project's specifics:  

target_id | The specific workflow or pipeline, such as build-ios or deploy-pipeline, allowing for granular status reporting. We strongly recommend using this variable to have a unique commit status for every target (workflow or pipeline)

event_type | The event triggering the status report, like pr (pull request), tag, or push.

project_slug | The unique, URL-friendly identifier for your project

project_title | The human-readable title of your project

Examples of dynamic values

By using dynamic variables, particularly target_id, you can achieve precise, target-specific status updates:

1app:
2  status_report_name: 'Primary checks using <target_id>'

Example output: Primary checks using ios-main-workflow

1app:  
2	status_report_name: 'Building feature branch using <target_id>'

Example output: Building feature branch using ios-main-workflow

You can even combine variables. Consider the examples below:

Feature branch testing

1app:  
2	status_report_name: 'Testing <target_id> for feature branch on <project_title>'

Example output: Testing ios-feature-test for feature branch on My Awesome App.
Context: Indicates that the feature branch is being tested within the iOS testing workflow.

Deployment process

1app:
2	status_report_name: 'Deployment initiated by <event_type> on <target_id>'

Example output: Deployment initiated by push on production-deploy.
Context: Reflects that a push event has triggered a deployment to production.

Build and test cycle

1app:
2	status_report_name: 'Build and test cycle for <project_slug> using <target_id>'

Example Output: Build and test cycle for my-awesome-app using build-and-test-pipeline
Context: Provides a comprehensive status for the build and test cycle of the specified project.

Multi-platform build

1app:
2	status_report_name: 'Building for all platforms on <target_id> of <project_title>'

Example output: Building for all platforms on cross-platform-build of My Awesome App
Context: Reflects the process of building the app for multiple platforms in a designated workflow.

Misc combinations

1app:  
2	status_report_name: 'Workflow: <target_id> | Event: <event_type>'

Example output: android_build | push

1app:
2	status_report_name: 'PR check for <project_title>'

Example output: PR check for My Awesome App

1app:
2	status_report_name: 'Deployment triggered by <event_type>'

Example output: Deployment triggered by push

1app:
2	status_report_name: 'Project: <project_title> | Workflow: <target_id> | Event: <event_type>'

Example output: Project: My Awesome App | Workflow: test-suite | Event: pr

These examples illustrate how combining multiple variables can give you a more complete picture of each commit's status, tailored to your project's specific workflows and events. By leveraging combinations like these, especially with the target_id variable, you can receive precise updates for each workflow or pipeline. You can ensure that your commit status messages provide maximum insight and clarity to all team members involved.

Static values: simplest option (but has scope limitations)

Static values allow you to set straightforward, consistent messages for your commit statuses. They are limited in scope. Static statuses (or any status not using the target_id variable) are replaced with each new workflow or pipeline run, potentially obscuring valuable information from earlier runs. Here are a few examples:

1app:
2	status_report_name: 'Bitrise Build'

1app:
2	status_report_name: 'Build for My Awesome App'

1app:
2	status_report_name: 'ci/bitrise/my-awesome-app/pr'

ℹ️ The path to clarity - Use dynamic variables with target_id

Leverage dynamic commit statuses and prioritize the target_id variable to give your team valuable insights. This will boost transparency and empower informed decision-making.

Target-level customization of status report

In addition to the project-level settings, you can personalize commit statuses at the workflow or pipeline level. You can even use the same YAML field at the workflow or pipeline level. This extra customization gives you more control over how each workflow or pipeline shares its status, making it easier to understand what's happening at a glance.

1workflows:
2	build-ios:   
3		status_report_name: 'iOS Build Status'

1pipelines:  
2	deploy-pipeline:    
3		status_report_name: 'Deployment Pipeline Status'

For workflows, you can achieve this using the UI too. Check out the screenshot below:

Code is better than clicks (at least in this context)

Using YAML to manage git commit statuses reduces the need to dig through the UI, letting your team quickly make updates right from their code editors. This speeds up your workflow and keeps everything consistent and well-organized, all within the same repository. With YAML, you can easily share and review your configurations, helping your team focus on what matters most—writing great code!

Ready to elevate your development workflow with custom commit statuses?

By embracing the power of dynamic commit statuses, especially those that incorporate the target_id variable, you're not just adding labels to your processes—you're crafting a narrative that keeps your team in sync. Imagine the confidence that comes when every team member, from developers to project managers, can instantly grasp the exact status of any workflow or pipeline. This transparency drives efficiency, and efficiency drives innovation. So go ahead and tap into this newfound clarity. Your team—and your code—deserve nothing less.

Get started with custom commit statuses today. Smoother workflows await.