GitHub Action for Managing Release Branches

This GitHub Action adopts a streamlined approach to managing release branches, drawing on a trunk-based branching strategy. In this model, the DEFAULT_BRANCH consistently represents the most recent release, while release branches are exclusively created for previous major releases, if applicable. This structure simplifies the process for contributors when submitting Pull Requests for bug fixes or backporting modifications to older releases, as it enables them to target a specific major release.

How it works: upon publishing a new major release N, a corresponding branch for the previous release N-1 will be automatically generated.

Imagine you have tags like this in your repo:

0.1.0
0.2.0
1.0.0
1.1.0
1.2.0
1.2.1
2.0.0
2.1.0
2.2.0
3.0.0
3.1.0   main

Upon the first release published event, the "release branch manager" will generate new branches named release/vN-1, where N corresponds to the latest tag of each major release. In this case, several new branches will be created:

0.1.0
0.2.0   release/v0
1.0.0
1.1.0
1.2.0
1.2.1   release/v1
2.0.0
2.1.0
2.2.0   release/v2
3.0.0
3.1.0   main

Note that 3.1.0 is latest tag and release branch manager wouldn't create release branch because latest major release is maintained in main branch.

If you wish to make changes to 2.2.0, you must create a pull request for the release/v2 branch and generate a corresponding release/tag with a major version of 2, for example, 2.3.0.

This action requires GitHub releases to follow the SemVer versioning scheme.

Example of workflow that that will create major release tags. To use it, just add this workflow to your .github/workflows directory.

  name: Manager Release Branch

  on:
    release:
      types:
        - published

  jobs:
    publish:
      runs-on: ubuntu-latest
      steps:
        - uses: cloudposse/github-action-release-branch-manager@v1

Check out these related projects.

• Major Release Tagger GitHub Action - GitHub Action that automatically generates or updates v<major-release> tags every time a new release is published.
• Release Label Validator GitHub Action - Verifies labels that are set on Pull Request

For additional context, refer to some of these links.

• Release Drafter GitHub Action - Drafts your next release notes as pull requests are merged into your default branch.
• Release Branch Manager GitHub Action - Automatically creates "Long Term Support (LTS)" release branches when new releases are published
• Major Release Tagger GitHub Action - GitHub Action that automatically generates or updates v<major-release> tags every time a new release is published.

This project is under active development, and we encourage contributions from our community.

Many thanks to our outstanding contributors:

For 🐛 bug reports & feature requests, please use the issue tracker.

In general, PRs are welcome. We follow the typical "fork-and-pull" Git workflow.

1. Review our Code of Conduct and Contributor Guidelines.
2. Fork the repo on GitHub
3. Clone the project to your own machine
4. Commit changes to your own branch
5. Push your work back up to your fork
6. Submit a Pull Request so that we can review your changes

NOTE: Be sure to merge the latest changes from "upstream" before making a pull request!## Running Terraform Tests

We use Atmos to streamline how Terraform tests are run. It centralizes configuration and wraps common test workflows with easy-to-use commands.

All tests are located in the test/ folder.

Under the hood, tests are powered by Terratest together with our internal Test Helpers library, providing robust infrastructure validation.

Setup dependencies:

• Install Atmos (installation guide)
• Install Go 1.24+ or newer
• Install Terraform or OpenTofu

To run tests:

• Run all tests:

  atmos test run

• Clean up test artifacts:

  atmos test clean

• Explore additional test options:

  atmos test --help

The configuration for test commands is centrally managed. To review what's being imported, see the atmos.yaml file.

Learn more about our automated testing in our documentation or implementing custom commands with atmos.

Join our Open Source Community on Slack. It's FREE for everyone! Our "SweetOps" community is where you get to talk with others who share a similar vision for how to rollout and manage infrastructure. This is the best place to talk shop, ask questions, solicit feedback, and work together as a community to build totally sweet infrastructure.

Sign up for our newsletter and join 3,000+ DevOps engineers, CTOs, and founders who get insider access to the latest DevOps trends, so you can always stay in the know. Dropped straight into your Inbox every week — and usually a 5-minute read.

Join us every Wednesday via Zoom for your weekly dose of insider DevOps trends, AWS news and Terraform insights, all sourced from our SweetOps community, plus a live Q&A that you can’t find anywhere else. It's FREE for everyone!

Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.  See the NOTICE file
distributed with this work for additional information
regarding copyright ownership.  The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at

  https://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License.

All other trademarks referenced herein are the property of their respective owners.

Copyright © 2017-2025 Cloud Posse, LLC