> For the complete documentation index, see [llms.txt](https://sealights-docs.tricentis.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sealights-docs.tricentis.com/january-2025/automatic-build-tagging-and-branching-out.md).

# Automatic Build Tagging & Branching Out

We're excited to introduce a powerful new set of capabilities designed to significantly automate your SeaLights **configuration management**: **Auto Build Tagging** and **Auto Branching Out of Configurations**.

### Why This Matters

Many organizations face the challenge of consistently applying **various configurations** across different development streams, including main branches, feature branches, release branches, and hotfix branches. Manually configuring these for each build or new branch can be time-consuming and prone to inconsistencies.

These new features address this by:

* **Automating Configuration Inheritance:** Ensuring that necessary configurations are automatically inherited from a designated baseline (e.g., your main branch, or a specific release build) to other builds.
* **Streamlining Build Management:** Automatically tagging your builds based on predefined rules, which then triggers the automated configuration inheritance.
* **Ensuring Consistency:** Reducing manual effort and human error in setting up configurations for various development and release streams.

### How It Works: A Seamless Automated Flow

Our approach automates this process by defining **configurations** between build tags. When a new build is created, it follows a two-step automated process:

1. **Auto Build Tagging:**

   * This capability allows new builds to be automatically tagged based on their branch naming pattern. This is useful for various scenarios, such as tagging builds on a new feature branch, a release candidate branch, or a hotfix branch.
   * You define **Build Tagging Rules** that link branch patterns (using regular expressions) to specific tags. For example, any branch starting with `feature/` could automatically get a `Feature` tag, or `release_*` branches could be tagged `RC`.
   * When a new build's branch name matches a configured pattern, the build is automatically assigned the corresponding tag.

   *Example Rule:*

   <pre data-overflow="wrap"><code>{
     "branchPattern": "release_*",
     "tag": "RC"
   }
   </code></pre>
2. **Auto Branching Out Configurations:**

   * Once a build is automatically tagged (or manually tagged via API), this capability enables the automatic inheritance or merging of configurations between a baseline tagged build and the newly tagged build. This is not limited to new branches; it can apply to any build that needs to inherit settings from a specific baseline.
   * You'll define **Branching Out Configurations** that specify which baseline tag to inherit from (e.g., `main`, `release-v1.0`), which configurations to apply, and whether this should apply only to the *first build* of a new branch or all builds with that tag.
   * When a tagged build meets the defined conditions (e.g., it's the first build of a new branch with a specific tag, or a new build on a release branch), the system automatically identifies the latest build with the corresponding baseline tag and triggers the branching process. This ensures the correct configuration inheritance is applied.

   *Example Configuration:*

   <pre data-overflow="wrap"><code>{
     "baselineTag": "main",
     "tag": "RC",
     "onlyFirstBuild": true,
     "configsToInherit": {
       "statisticalModel": true,
       "pinnedTests": true,
       "testDependencies": true,
       "commonCode": false
     }
   }
   </code></pre>

**The Automated Flow:** The Auto Build Tagging process (often the first step) automatically applies a tag to your new build. This applied tag then triggers the Auto Branching Out process, ensuring seamless inheritance of your configurations from the main branch or another designated baseline.

### Important Use Case: Release Branches

For clients managing release branches where each branch is created from the previous release, the process can also be automated. Instead of relying solely on auto-tagging, you can use our **Public API to tag the released build for each branch**. With the correct auto-branching-out configuration settings, each new build for the next release will then automatically branch out from the latest release, ensuring continuous **configuration inheritance**.

### Examples of Inheritable Configurations

This new capability can be used for managing various types of configurations. Common applications include:

* **Test Impact Analysis (TIA) Configurations:**
  * **Statistical Model (SM)**
  * **Test Dependencies**
  * **Pinned Tests**
  * **Common Code**
* **Code Changes Comparison Baselines:** Automatically setting the baseline for code changes comparison to a build from a different branch (e.g., comparing a feature branch to the latest `main` build).

By using Auto Build Tagging and Auto Branching Out, you can ensure these critical settings are consistently applied across your development branches and release cycles without manual intervention.

{% hint style="info" %}
Learn more about [Auto Branching Out](https://api-doc.sealights.io/#6988310e-6a5b-4ebe-ab24-c50a7f21e471)
{% endhint %}