Adding changelog configuration categories to release-please

[camillecroft]

Issue

We need to update the changelog categories to support the commit prefixes used across the CSDA repos. Adding changelog-sections to the csda-version release-please-config.json file only affects the local repository. Repositories currently using the csda-version action are defaulting to the "Features" and "Bug Fixes" categories.

Release Please fetches its configuration directly from the Git tree via the GitHub API, rather than reading from the local runner's filesystem. This means configuration cannot be dynamically injected or fetched from external sources at runtime. The config and manifest files must be at the root of each repository.

Option 1: Downgrade to version 3

In version 3 the changelog types can be defined as an input field for the release-please action. This allows us to add the changelog types as an output within the csda-version repo.

Setup Example:

csda-version/action.yml

    - name: Set changelog types
      id: changelog-types
      shell: bash
      run: |
        cat >> "$GITHUB_OUTPUT" << 'EOF'
        changelog-types<<CHANGELOG_EOF
        [
          { "type": "feat", "section": "Features", "hidden": false },
          { "type": "fix", "section": "Bug Fixes", "hidden": false },
          { "type": "refactor", "section": "Refactor", "hidden": false },
          { "type": "chore", "section": "Chores", "hidden": false },
          { "type": "docs", "section": "Documentation", "hidden": false },
          { "type": "revert", "section": "Revert", "hidden": false }
        ]
        CHANGELOG_EOF
        EOF

<csda-repo>/.github/workflows/release-please.yaml:

      - uses: googleapis/release-please-action@v3
        id: release-please
        with:
          release-as: ${{ steps.get-workflow.outputs.version }}
          release-type: python
          changelog-types: ${{ steps.get-workflow.outputs.changelog-types }}

Option 2: Use version 5

In versions 4 and 5, you can no longer define changelog types directly in the release-please-config.json. release-please-config.json and .release-please-manifest.json files need to be located at the repository root.

Testing

Tested this configuration between two repositories.

[camillecroft]

@emmalu @gadomski Let me know if you have any thoughts on this! Leaning towards downgrading to version 3.

[gadomski]

To me it's not worth staying on old versions of release-please just for CHANGELOG management. I'd rather just update our expectations of what's the in CHANGELOG and what prefixes we use for PRs.

[emmalu]

I'm also not sure that downgrading is the right move, considering it's a bit counter to security advice to stay as up-to-date as possible. That said, I'm also weary of asking our teams to update our expectations of what's in the CHANGELOG. Does option 2 mean each repo would need a copy of the config file? Or am I misunderstanding?

[camillecroft]

I'm also not sure that downgrading is the right move, considering it's a bit counter to security advice to stay as up-to-date as possible. That said, I'm also weary of asking our teams to update our expectations of what's in the CHANGELOG. Does option 2 mean each repo would need a copy of the config file? Or am I misunderstanding?

Yes there would need to be a copy of .release-please-manifest.json and release-please-config.json in each repo.

[camillecroft]

Run into a roadblock with upgrading to v5 and including a custom changelog. In release please v5, the manifest file defines the release version. If release-as is defined in the config and conflicts with the manifest, it will default to the manifest value. It cannot be overridden.
There is a benefit with a custom changlog, as the chore prefix is often used. Using version 3 would be a viable solution.

[emmalu]

So both newer versions are flawed?! 😭

[camillecroft]

So both newer versions are flawed?! 😭

Yes 😭, version 4+ moved away from individual action inputs and was replaced with a centralized manifest-based configuration.