Skip to content

Automating Releases with Changesets, GitHub Apps, and Policy Bot

Overview

This document summarizes automating release workflows in GitHub using Changesets while maintaining repository policies and avoiding workflow issues such as infinite CI loops. It explains the challenges encountered and the recommended setup used internally.

1. Initial Problem: Pull Requests Not Triggering CI

The initial issue occurred when automatically created pull requests did not trigger CI workflows. This happens when a pull request is created using the default GitHub-provided workflow token.

GitHub intentionally prevents workflows triggered by this token from triggering additional workflows to avoid infinite automation loops.

Example of such a loop

  1. A workflow creates a pull request
  2. The pull request triggers another workflow
  3. That workflow creates another pull request
  4. The process repeats indefinitely

To prevent uncontrolled CI usage and resource consumption, GitHub blocks this behavior.

2. Solution: Using a GitHub App Token

To allow workflows to trigger other workflows, an alternative authentication method is required. The recommended approach is to create and use a GitHub App that generates short‑lived tokens.

Implementation Steps

  1. Create a GitHub App in the organization
  2. Retrieve the App ID and Private Key
  3. Store these values as repository secrets
  4. Use a GitHub Action to generate an installation token during the workflow

Advantages

  • Tokens are not tied to a specific user account
  • Tokens are short‑lived (typically about one hour)
  • They are automatically invalidated
  • Workflows triggered with this token can trigger additional workflows

Using a Personal Access Token (PAT) would technically work but is discouraged because it is linked to a specific user account and may break if that user leaves the organization.

3. Handling Approval Restrictions

Many repositories enforce branch protection rules requiring pull request approvals before merging. However, automated workflows cannot approve their own pull requests, which blocks automated release workflows.

To solve this, the setup uses a Policy Bot to manage approval rules outside of GitHub’s built‑in approval configuration.

4. Using Policy Bot for Flexible Approval Rules

Instead of relying on GitHub’s standard approval requirements, a Policy Bot is configured as a required status check.

The bot evaluates rules defined in a policy configuration file stored in the repository.

Key Characteristics

  • GitHub branch rules do not require approvals directly
  • The Policy Bot acts as a required check
  • Pull requests can only be merged when the Policy Bot returns success
  • Approval logic is defined in a YAML policy file

This allows flexible rule definitions.

5. Example Rules

Automated Release PRs (Changesets)

Rules can allow automatic merging when:

  • The PR title matches the default Changesets title (e.g. "Version Packages")
  • The PR author is GitHub Actions or the GitHub App
  • The PR was created by the release automation

In this case no manual approval is required.

Renovate Dependency Updates

For dependency update PRs created by Renovate:

Conditions:

  • PR author is Renovate
  • PR contains a Renovate label

Result:

  • The PR can be merged without manual approval.

Regular Pull Requests

For normal development pull requests:

Requirement:

  • At least one approval from a designated maintainer group

Only then can the PR be merged.

6. Automated Release Workflow

With this setup, fully automated releases become possible.

Typical Workflow

  1. Developers add changesets during development
  2. Changesets generates a release pull request
  3. CI workflows run automatically
  4. The Policy Bot evaluates the rules
  5. If conditions are satisfied, the PR can be merged automatically

Some teams also configure scheduled workflows that automatically publish releases (for example weekly) whenever new changes were introduced. This ensures that updates and security fixes are regularly released without manual intervention.

7. When Full Automation Is Not Necessary

For smaller repositories or internal libraries with few consumers, full automation may not be necessary.

In these cases the Changesets pull request can simply be reviewed and merged manually.

Typically, the automated PR only:

  • Updates the changelog
  • Removes processed changeset files
  • Bumps the version number

Therefore, the review effort is usually minimal.

Summary

The recommended setup for reliable automated releases in GitHub consists of:

  • Using Changesets to generate release pull requests
  • Creating pull requests using a GitHub App token instead of the default workflow token
  • Managing approval policies through a Policy Bot
  • Allowing automated PRs (Changesets or Renovate) to bypass manual approvals
  • Optionally running scheduled release workflows

This architecture prevents CI loops, removes dependency on personal tokens, and enables flexible automation policies.

Last updated: March 11, 2026 at 16:51
By: Markus Wolf