Hotfix

Everything about hotfix-type issues.

Hotfix issues are used to track and resolve critical bugs that need immediate attention in the production environment. These issues help maintain the stability of the production codebase by addressing urgent problems that affect functionality.

Workflow

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

  • Create Hotfix Branch

    A hotfix branch is created from main-branch at the latest tag version

  • Create Bugfix Branch

    A bugfix branch is created from the hotfix branch to implement the fix

  • Implement Changes

    The needed changes are applied on the bugfix branch

  • Merge Bugfix

    The bugfix is merged back into the hotfix branch via Pull Request

  • Deploy New Version

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

  • Merge Hotfix

    After successful deployment, the hotfix branch is merged:

    • First into main-branch with the new version tag
    • Then 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 critical fixes reach production quickly while maintaining code quality and proper version control. The process is designed to minimize disruption while addressing urgent issues.

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

How do I trigger the hotfix deployment?

Once your bug fix is merged into the hotfix branch and ready for deployment, simply add the deploy-label to the issue. This will automatically trigger the hotfix deployment workflow.

By default, the deployment is triggered with the deploy label and uses the hotfix_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
          hotfix-workflow: hotfix_workflow.yml

How do I control the end of the deployment?

The hotfix deployment workflow is defined in the hotfix_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 - Hotfix

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Hotfix 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 hotfix issue #123 fixing a critical login bug:

  1. Hotfix branch created: hotfix/1.2.4
  2. Bugfix branch created: bugfix/123-fix-critical-login
  3. Fix implemented and tested on bugfix branch
  4. PR merged into hotfix/1.2.4
  5. Version 1.2.4 deployed to production
  6. Changes merged to master and develop

Label

All hotfix issues are created with the hotfix-label. The default label for creating a hotfix-type issue is hotfix. 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:
          hotfix-label: hotfix

Naming

The default tree for creating hotfix branches is hotfix. 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:
          hotfix-tree: hotfix

Hotfix branches follow this naming convention:

hotfix/hotfix-version

For example:

hotfix/1.2.3

Source

Hotfix branches are created from the master branch, specifically from the latest published tag. This ensures that hotfixes are based on the most recent stable production code. You can configure the master branch name as shown below:

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

Images

You can configure custom images to be displayed in the comments of hotfix 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-hotfix input:

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

Template

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

  • Base version selection
  • Hotfix version specification
  • Detailed issue description
  • Proposed hotfix solution
  • Additional context and comments

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

name: 🔥 Hotfix Issue

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

        ---

  - type: input
    id: base_version
    attributes:
      label: Base Version
      description: |
        The base version is typically the most recent tag version. However, you can specify a different version tag if you'd like to start from a specific version for this hotfix.
      placeholder: "e.g., 1.2.3"
      value: "Automatic"
    validations:
      required: false

  - type: input
    id: hotfix_version
    attributes:
      label: Hotfix Version
      description: |
        By default, the version will increment the patch number of the most recent tag version (e.g., from 1.2.3 to 1.2.4). You can specify a different version number for the hotfix if needed.
      placeholder: "e.g., 1.2.4"
      value: "Automatic"
    validations:
      required: false

  - type: textarea
    id: issue_description
    attributes:
      label: Issue Description
      description: |
        Provide a detailed description of the issue this hotfix is addressing.
      placeholder: "Describe the issue being fixed."
    validations:
      required: true

  - type: textarea
    id: hotfix_solution
    attributes:
      label: Hotfix Solution
      description: |
        Explain the solution being implemented in this hotfix.
      placeholder: "Describe the solution."
    validations:
      required: true

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