Track the count of subfeatures that were merged into a feature branch?

[tomerh2001]

Hello, I am looking for a way to count the sub features that were merged into a feature branch.
For example:

1. My main branch is develop.
2. My feature branches are proj-<jira issue>/<title>.
3. and my sub-features are also proj-<jira issue>/<title>, but are merged into the feature branch instead of develop.

The expected behavior I want:

1. Merging feature branch into develop: bumps the version normally.
2. Merging a sub-feature into a feature branch: bumps the counter in the version, I.E. <version after feature branch>-beta.<sub features count>

I'm sure there's a way to do it, but I haven't managed to get it working without semantic release getting mad at me. Any help? thanks :)

[tomerh2001]

This is my attempt:

Configuration:

branches:
  - name: develop
  - name: main
  - name: proj-*/*
    prerelease: "beta"
plugins:
  - "@semantic-release/commit-analyzer"
  - "@semantic-release/release-notes-generator"
  - "@semantic-release/changelog"
  - "@semantic-release/git"

Error:

$ bunx semantic-release -d
[15:23:05] [semantic-release] » ℹ  Running semantic-release version 23.0.7
[15:23:05] [semantic-release] » ✔  Loaded plugin "verifyConditions" from "@semantic-release/changelog"
[15:23:05] [semantic-release] » ✔  Loaded plugin "verifyConditions" from "@semantic-release/git"
[15:23:05] [semantic-release] » ✔  Loaded plugin "analyzeCommits" from "@semantic-release/commit-analyzer"
[15:23:05] [semantic-release] » ✔  Loaded plugin "generateNotes" from "@semantic-release/release-notes-generator"
[15:23:05] [semantic-release] » ✔  Loaded plugin "prepare" from "@semantic-release/changelog"
[15:23:05] [semantic-release] » ✔  Loaded plugin "prepare" from "@semantic-release/git"
[15:23:58] [semantic-release] » ✘  EPRERELEASEBRANCHES The pre-release branches are invalid in the `branches` configuration.
Each pre-release branch in the branches configuration (https://github.com/semantic-release/semantic-release/blob/master/docs/usage/configuration.md#branches) must have a unique prerelease property. If the prerelease property is set to true, then the name property is used instead.

Your configuration for the problematic branches is [ { channel: 'proj-58/new-project', type: 'prerelease', name: 'proj-58/new-project', prerelease: 'beta', tags: [ [Object], [Object], [Object], [Object], [Object], ... 36 more items ] }, { channel: 'proj-65/server-repo', type: 'prerelease', name: 'proj-65/server-repo', prerelease: 'beta', tags: [ [Object], [Object], [Object], [Object], [Object], ... 19 more items ] }, { channel: 'proj-66/server-should-not-serve-client', type: 'prerelease', name: 'proj-66/server-should-not-serve-client', prerelease: 'beta', tags: [ [Object], [Object], [Object], [Object], [Object], ... 19 more items ] }, { channel: 'proj-67/AWS', type: 'prerelease', name: 'proj-67/AWS', prerelease: 'beta', tags: [ [Object], [Object], [Object], [Object], [Object], ... 19 more items ] }, { channel: 'proj-74/somplo', type: 'prerelease', name: 'proj-74/somplo', prerelease: 'beta', tags: [ [Object], [Object], [Object], [Object], [Object], ... 19 more items ] } ].

AggregateError:
    SemanticReleaseError: The pre-release branches are invalid in the `branches` configuration.
        at default (file:///C:/projects/RC/proj-workspace/projects/routines/node_modules/semantic-release/lib/get-error.js:6:10)
        at file:///C:/projects/RC/proj-workspace/projects/routines/node_modules/semantic-release/lib/branches/index.js:45:19
        at Array.reduce (<anonymous>)
        at default (file:///C:/projects/RC/proj-workspace/projects/routines/node_modules/semantic-release/lib/branches/index.js:35:46)
        at async run (file:///C:/projects/RC/proj-workspace/projects/routines/node_modules/semantic-release/index.js:68:22)
        at async Module.default (file:///C:/projects/RC/proj-workspace/projects/routines/node_modules/semantic-release/index.js:278:22)
        at async default (file:///C:/projects/RC/proj-workspace/projects/routines/node_modules/semantic-release/cli.js:55:5)
    at default (file:///C:/projects/RC/proj-workspace/projects/routines/node_modules/semantic-release/lib/branches/index.js:67:11)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async run (file:///C:/projects/RC/proj-workspace/projects/routines/node_modules/semantic-release/index.js:68:22)
    at async Module.default (file:///C:/projects/RC/proj-workspace/projects/routines/node_modules/semantic-release/index.js:278:22)
    at async default (file:///C:/projects/RC/proj-workspace/projects/routines/node_modules/semantic-release/cli.js:55:5) {
  errors: [
    SemanticReleaseError: The pre-release branches are invalid in the `branches` configuration.
        at default (file:///C:/projects/RC/proj-workspace/projects/routines/node_modules/semantic-release/lib/get-error.js:6:10)
        at file:///C:/projects/RC/proj-workspace/projects/routines/node_modules/semantic-release/lib/branches/index.js:45:19
        at Array.reduce (<anonymous>)
        at default (file:///C:/projects/RC/proj-workspace/projects/routines/node_modules/semantic-release/lib/branches/index.js:35:46)
        at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
        at async run (file:///C:/projects/RC/proj-workspace/projects/routines/node_modules/semantic-release/index.js:68:22)
        at async Module.default (file:///C:/projects/RC/proj-workspace/projects/routines/node_modules/semantic-release/index.js:278:22)
        at async default (file:///C:/projects/RC/proj-workspace/projects/routines/node_modules/semantic-release/cli.js:55:5) {
      code: 'EPRERELEASEBRANCHES',
      details: 'Each pre-release branch in the [branches configuration](https://github.com/semantic-release/semantic-release/blob/master/docs/usage/configuration.md#branches) must have a unique `prerelease` property. If the `prerelease` property is set to `true`, then the `name` property is used instead.\n' +
        '\n' +
        "Your configuration for the problematic branches is `[ { channel: 'proj-58/new-project', type: 'prerelease', name: 'proj-58/new-project', prerelease: 'beta', tags: [ [Object], [Object], [Object], [Object], [Object], ... 36 more items ] }, { channel: 'proj-65/server-repo', type: 'prerelease', name: 'proj-65/server-repo', prerelease: 'beta', tags: [ [Object], [Object], [Object], [Object], [Object], ... 19 more items ] }, { channel: 'proj-66/server-should-not-serve-client', type: 'prerelease', name: 'proj-66/server-should-not-serve-client', prerelease: 'beta', tags: [ [Object], [Object], [Object], [Object], [Object], ... 19 more items ] }, { channel: 'proj-67/AWS', type: 'prerelease', name: 'proj-67/AWS', prerelease: 'beta', tags: [ [Object], [Object], [Object], [Object], [Object], ... 19 more items ] }, { channel: 'proj-74/somplo', type: 'prerelease', name: 'proj-74/somplo', prerelease: 'beta', tags: [ [Object], [Object], [Object], [Object], [Object], ... 19 more items ] } ]`.",
      semanticRelease: true
    }
  ]
}

I want all features and subfeatures to be counted towards <version>-beta.<counter>, I don't want each subfeature to have it's own version i.e. <version>-<subfeature>-beta.<count>, this is just horrendous and complicates things more...

[travi]

seeing your config above and your response to this other thread, it seems like you are not understanding the feedback from that other thread. the error you are hitting is related specifically to the / character in your branch pattern.

however, even if your branch pattern was supported, your target workflow is not one that we officially support, so providing support beyond what you are able to figure out on your own is unlikely to be something we will be giving priority to.

[travi]

The expected behavior I want:

1. Merging feature branch into develop: bumps the version normally.
2. Merging a sub-feature into a feature branch: bumps the counter in the version, I.E. <version after feature branch>-beta.<sub features count>

this behavior aligns to the behavior of the pre-release workflow, which does increment versions as you describe as long as the pre-release branch has the necessary previous versions in the history of the branch and the branch configuration is defined in a supported way

For example:

1. My main branch is develop.
2. My feature branches are proj-<jira issue>/<title>.
3. and my sub-features are also proj-<jira issue>/<title>, but are merged into the feature branch instead of develop.

however, you have multiple problems with the context in which you want semantic-release to match your desired behavior.

• you are describing a git-flow workflow, which is not officially supported by semantic-release
• while the behavior you desire looks sort of like what the pre-release workflow enables, the pre-release workflow is not designed to support git-flow. git-flow is a different workflow than a pre-release workflow, so using it for your target is unsupported
• releasing for all of your feature branches rather than merging and simply releasing as stable releases is not something we encourage, especially if your feature branch naming pattern uses a format that we do not support