Proposal: Integrate release-please into Our Release Workflow

1. Context & Current Process

• Repository: Project built and released via GoReleaser.
• Current Flow:
  1. Developer pushes feature branch → opens PR.
  2. After PR merge, manually bump version tag (e.g. v1.2.3).
  3. Push tag → CI triggers GoReleaser → generates GitHub Release + binaries.
  4. Manually write changelog notes in GitHub release interface.

2. Proposed Integration

Introduce release-please (GitHub Action) to automate:

1. Release PR creation with draft release notes & bump - active/automating tracking of next release.
2. Changelog generation based on Conventional Commits - Zarf does not maintain a CHANGELOG currently.
3. Tag push upon PR merge → triggers GoReleaser as today.

Workflow Diagram

feature PR → merge → release-please PR → merge → tag push → GoReleaser → GitHub Release

3. Advantages

4. Validation & Quality Gates

4.1. Commit Message Conventions

• Adopt Conventional Commits (https://www.conventionalcommits.org/en/v1.0.0/).
• Types include: feat, fix, docs, chore, refactor, perf, test.
• Enforcement: Add commitlint in CI.

  jobs:
    title_check:
      runs-on: ubuntu-latest
      defaults:
        run:
          working-directory: commitlint
  
      steps:
        - name: Checkout
          uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
          with:
            fetch-depth: 0
  
        - name: Setup Node.js
          uses: actions/setup-node@1d0ff469b7ec7b3cb9d8673fde0c81c44821de2a # v4.2.0
  
  
        - name: Install commitlint
          run: npm ci --only=dev
  
        - name: Lint PR title
          env:
            PR_TITLE: ${{ github.event.pull_request.title }}
          run: echo "$PR_TITLE" | npx commitlint

4.2. Pull Request Title Linting
Mirror commit rules in PR titles to group related changes.

4.3. CI Pipeline Adjustments
Branch protection:

Require “lint-commits” status on feature PRs.

Protect main so only release-please PRs can push tags.

Test coverage: Ensure full test suite passes before merging release-please PR.

4.4. Semantic Versioning Strategy
Decide on yield for breaking changes (BREAKING CHANGE: → major bump).

Validate that developers mark BREAKING CHANGE scopes when necessary.

4.5. Access & Permissions
Grant release-please[bot] permission to push to main.

5. Implementation Plan
   Prep & Onboard

Add release-please-config.json with target files (go.mod, CHANGELOG.md).

Create commitlint.config.js for Conventional Commits rules.

Configure GitHub Actions

Add release-please action on main merge:

on:
  push:
    branches:
      - main
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Create Release PR
        uses: google-github-actions/release-please-action@v3
        with:
          release-type: go
          package-name: "github.com/org/repo"

6. Next Steps
   Team Review of proposal.

Prototype on a feature branch.

Iterate based on team feedback.

Cut Over once stable; deprecate manual bump step.