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-branchCreate 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-labelto the issueMerge Release Branch
After successful deployment, the release branch is merged:
- First into
main-branchwith the new version tag - Then back into
development-branchto keep changes synchronized
- First into
Close Issue
The issue is automatically closed with the
deployed-labellabel once the process completes
This workflow ensures that releases are properly planned, tested, and deployed while maintaining code quality and proper version control.
.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 numbertitle: Title for the releasechangelog: Description of changesissue: ID of the originating issue
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:
- Release branch created:
release/1.3.0 - Feature branch created:
feature/456-finalize-changelog - Changes applied and tested on feature branch
- PR merged into
release/1.3.0 - Version 1.3.0 deployed to production (add
deploylabel to the issue) - Release branch merged to
master(with tag) and back intodevelop
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?"