Release

Everything about release-type issues.

Release issues are used to track and manage the process of creating new versions of your software. These issues help coordinate the release process, ensuring that all planned features and fixes are properly integrated and tested before being deployed to production.

Workflow

The release process follows these steps after creating an issue with release and branched labels:

  • Create Release Branch

    A release branch is created from development-branch

  • Create Feature Branch

    A feature branch is created from the release branch to implement any remaining changes

  • Apply Changes

    The needed changes are applied on the feature branch

  • Merge Feature Branch

    The feature branch is merged back into the release branch via Pull Request

  • Deploy New Version

    A new version is deployed from the release branch by adding the deploy-label to the issue

  • Merge Release Branch

    After successful deployment, the release branch is merged:

    • First into main-branch with the new version tag
    • Then back into development-branch to keep changes synchronized
  • Close Issue

    The issue is automatically closed with the deployed-label label once the process completes

This workflow ensures that releases are properly planned, tested, and deployed while maintaining code quality and proper version control.

Deploy workflow files should be located in the .github/workflows directory of your repository.

How do I trigger the release deployment?

Once your changes are merged into the release branch and ready for deployment, simply add the deploy-label to the issue. This will automatically trigger the release deployment workflow.

By default, the deployment is triggered with the deploy label and uses the release_workflow.yml workflow file. You can customize these settings as shown below:

jobs:
  git-board-issues:
    name: Git Board - Issue
    runs-on: ubuntu-latest
    steps:
      - uses: vypdev/copilot@v2
        with:
          deploy-label: deploy
          release-workflow: release_workflow.yml

How do I control the end of the deployment?

The release deployment workflow is defined in the release_workflow.yml file.

The workflow requires the following inputs:

  • version: The new version number
  • title: Title for the release
  • changelog: Description of changes
  • issue: ID of the originating issue
Remember to create a new tag for the new deployed version.
name: Task - Release

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Release version'
        required: true
        default: '1.0.0'
      title:
        description: 'Title'
        required: true
        default: 'New Version'
      changelog:
        description: 'Changelog'
        required: true
        default: '- Several improvements'
      issue:
        description: 'Launcher issue'
        required: true
        default: '-1'

jobs:
  deploy:
    name: Git Board - Issue
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v4

      // create a new tag version here

      // deploy logic here

      - name: Git Board - Deploy success notification
        uses: vypdev/copilot@v2
        if: ${{ success() }}
        with:
          single-action: 'deployed_action'
          single-action-issue: '${{ github.event.inputs.issue }}'
          token: ${{ secrets.PAT }}

Example

For a release issue #456 releasing version 1.3.0:

  1. Release branch created: release/1.3.0
  2. Feature branch created: feature/456-finalize-changelog
  3. Changes applied and tested on feature branch
  4. PR merged into release/1.3.0
  5. Version 1.3.0 deployed to production (add deploy label to the issue)
  6. Release branch merged to master (with tag) and back into develop

Label

All release issues are created with the release-label. The default label for creating a release-type issue is release. You can configure this label as follows:

jobs:
  git-board-issues:
    name: Git Board - Issue
    runs-on: ubuntu-latest
    steps:
      - uses: vypdev/copilot@v2
        with:
          release-label: release

Naming

The default tree for creating release branches is release. You can configure this tree name as follows:

jobs:
  git-board-issues:
    name: Git Board - Issue
    runs-on: ubuntu-latest
    steps:
      - uses: vypdev/copilot@v2
        with:
          release-tree: release

Release branches follow this naming convention:

release/version

For example:

release/1.2.3

Source

Release branches are created from the development branch, ensuring that all planned features and fixes are included in the release. You can configure the development branch name as shown below:

jobs:
  git-board-issues:
    name: Git Board - Issue
    runs-on: ubuntu-latest
    steps:
      - uses: vypdev/copilot@v2
        with:
          development-branch: development

Images

You can configure custom images to be displayed in the comments of release issues. These images will be randomly selected and displayed when Copilot performs actions on the issue.

To configure the images, provide a comma-separated list of image URLs in the images-issue-release input:

jobs:
  git-board-issues:
    name: Git Board - Issue
    runs-on: ubuntu-latest
    steps:
      - uses: vypdev/copilot@v2
        with:
          images-issue-release: url1, url2, url3

Template

You can use this template for release issues that helps capture all the necessary information. The template includes fields for:

  • Release type selection (Major/Minor/Patch)
  • Version number (automatic or custom)
  • Changelog details
  • Additional context

You can find this template in .github/ISSUE_TEMPLATE/release.yml. Below is an example of how the template looks when creating a new release issue:

name: 🚀 Release Issue
description: Request a new release for copilot (only team members)
title: "<YOUR TITLE HERE>"
labels: ["release", "branched"]
body:
  - type: markdown
    attributes:
      value: |
        ### ⚠️ Disclaimer
        > **Only members of the copilot team can create release issues.**
        > Any release issue created by someone outside the team will be closed automatically.

        ---

  - type: dropdown
    id: release_type
    attributes:
      label: Release Type
      description: Indicate the type of release.
      options:
        - Major
        - Minor
        - Patch
    validations:
      required: true

  - type: input
    id: version
    attributes:
      label: Release Version
      description: The new version is generated from the release type and the most recent tag version. You can specify a different version number for the release (e.g., 1.2.3).
      placeholder: "e.g., 1.2.3"
      value: "Automatic"
    validations:
      required: false

  - type: textarea
    id: changelog
    attributes:
      label: Changelog
      description: Provide a summary of the changes to be included in this release.
      placeholder: "Add a concise changelog here."
    validations:
      required: true

  - type: textarea
    id: additional_context
    attributes:
      label: Additional Context
      description: Add any additional details or context about this release request.
      placeholder: "Anything else to note?"