The changelog format has been updated in this PR to more closely match the https://keepachangelog.com format (which allows reusing the regexes from our other automation), however, to reduce churn I've not adopted the change categories headings for now.
For now this is not being implemented as a shared workflow, since the classic buildpacks (unlike the CNBs):
do not have standardised changelog formats
have differing approaches to versioning (some have the changelog version match the buildpack registry version, others do not)
in some cases (eg Ruby) require additional edits for releases beyond just the changelog (such as updating version constants elsewhere in the codebase).
As such, it makes more sense to get something working for one buildpack first, and if there is interest about adding this to other classic buildpacks, we can discuss how we might standardise/implement generic automation.
Add a GitHub Actions workflow for preparing a new buildpack release, similar to that used for CNBs and
libcnb.rsreleases: https://github.com/heroku/languages-github-actions/blob/main/.github/workflows/_buildpacks-prepare-release.yml https://github.com/heroku/libcnb.rs/blob/main/.github/workflows/prepare-release.ymlThe changelog format has been updated in this PR to more closely match the https://keepachangelog.com format (which allows reusing the regexes from our other automation), however, to reduce churn I've not adopted the change categories headings for now.
For now this is not being implemented as a shared workflow, since the classic buildpacks (unlike the CNBs):
As such, it makes more sense to get something working for one buildpack first, and if there is interest about adding this to other classic buildpacks, we can discuss how we might standardise/implement generic automation.
GUS-W-14437037.