Fix git-flow init failure: use feature/main-dummy as production branch

[Copilot]

git flow init requires distinct production and development branches — the workflow was setting both gitflow.branch.master and gitflow.branch.develop to feature/component-release, causing Fatal: Production and integration branches should differ.

Changes

• gitflow.branch.master → feature/main-dummy (was feature/component-release)
• Ensure production branch exists locally before git flow init -d -f:

  git fetch origin feature/main-dummy:feature/main-dummy 2>/dev/null || git branch feature/main-dummy feature/component-release

• "Finish release and push" — added git push origin feature/main-dummy so git-flow's merge back into the production branch is pushed to remote

Original prompt

Problem

The component-release.yml GitHub Actions workflow on the feature/component-release branch fails with:

Fatal: Production and integration branches should differ.

This happens because both gitflow.branch.master and gitflow.branch.develop are set to feature/component-release, and git-flow requires these to be different branches.

Required Fix

In .github/workflows/component-release.yml, in the "Start release, generate changelog and publish" step, make the following changes:

1. Change gitflow.branch.master from feature/component-release to feature/main-dummy (a new branch that has been created for this purpose).
2. Keep gitflow.branch.develop as feature/component-release.
3. After the config block and before git flow init -d -f, add a line to ensure the feature/main-dummy branch exists locally:

   git fetch origin feature/main-dummy:feature/main-dummy 2>/dev/null || git branch feature/main-dummy feature/component-release
   

The config block should look like:

          # Configure git-flow to use feature/main-dummy as master and feature/component-release as develop
          git config gitflow.branch.master feature/main-dummy
          git config gitflow.branch.develop feature/component-release
          git config gitflow.prefix.feature feature/
          git config gitflow.prefix.bugfix bugfix/
          git config gitflow.prefix.release release/
          git config gitflow.prefix.hotfix hotfix/
          git config gitflow.prefix.support support/
          git config gitflow.prefix.versiontag ''

          # Ensure the production branch exists locally
          git fetch origin feature/main-dummy:feature/main-dummy 2>/dev/null || git branch feature/main-dummy feature/component-release

          # Initialize git-flow (required for git flow commands to work)
          git flow init -d -f

4. Also update the "Finish release and push" step to push both branches and tags:

      - name: Finish release and push
        run: |
          set -e
          git flow release finish -m "$RELEASE_VERSION release" "$RELEASE_VERSION"
          git push origin feature/component-release
          git push origin feature/main-dummy
          git push origin --tags

File to modify

• .github/workflows/component-release.yml (on branch feature/component-release)

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: No version type found in PR description, defaulting to PATCH increment.
Using calculated version: 5.0.1
Fatal: Not a gitflow-enabled repo yet. Please run 'git flow init' first.
Error: Process completed with exit code 1.

go this error.
how to make the git flow run.
PS: dont worry about the "No version type found in PR description, defaulting to PATCH increment." message.

Assistant: The component-release.yml workflow is not in this repo — it's likely a reusable workflow from another repository (like rdkcentral/build_tools_workflows or similar). Let me check where the actual workflow is coming from.

Assistant: ## Root Cause

The error is clear:

Fatal: Not a gitflow-enabled repo yet. Please run 'git flow init' first.

The "Component Release" workflow (.github/workflows/component-release.yml) is using a git flow release command (likely git flow release start or git flow release finish) to create release version 5.0.1. However, the GitHub Actions runner checks out a fresh copy of the repo each time, and git-flow is not initialized in that fresh checkout.

Why This Happens

git flow init creates local configuration (stored in .git/config) that defines which branches map to master, develop, feature/, release/, hotfix/, etc. Since GitHub Actions runners start with a clean clone every time, this local configuration does not persist between runs.

How to Fix

You need to add a git flow init step before the step that runs the git flow release command in your workflow. The workflow file is component-release.yml — based on the logs, it appears to be a reusable/called workflow (possibly from another repo like rdkcentral/cmf-actions or similar, since it's not directly visible in rdkcentral/sysint).

Add something like this before the git flow release step:

- name: Initialize git flow
  run: |
    git flow init -d

The -d flag accepts all default branch naming conventions automatically (no interactive prompts), which is essential for CI:

• Production branch: master (or main)
• Development branch: develop
• Feature prefix: feature/
• Release prefix: release/
• Hotfix prefix: hotfix/

If your repo uses main instead of master

If the default production branch is main rather than master, you'll need to specify it explicitly:

- name: Initialize git flow
  run: |
    git flow init -d -...

</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

*This pull request was created from Copilot chat.*
>

version:patch

[Copilot]

Pull request overview

Updates the component-release GitHub Actions workflow to successfully initialize git-flow by using distinct production and development branches, addressing the Fatal: Production and integration branches should differ. failure during releases.

Changes:

• Switch gitflow.branch.master to feature/main-dummy while keeping gitflow.branch.develop as feature/component-release.
• Ensure feature/main-dummy exists locally before running git flow init.
• Push feature/main-dummy after git flow release finish so the production-branch merge is published to the remote.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.