Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add a "Prepare release" workflow for classic buildpacks #184

Merged
merged 4 commits into from
Jan 26, 2024
Merged

Add a "Prepare release" workflow for classic buildpacks #184

merged 4 commits into from
Jan 26, 2024

Commits on Jan 26, 2024

  1. Add a prepare release workflow for classic buildpacks 

    This new workflow is based on the prepare release workflow used
by the classic Python buildpack:
https://github.com/heroku/heroku-buildpack-python/blob/main/.github/workflows/prepare-release.yml

However, as part of porting, the following changes have been made:
- The workflow now uses Git tags as the source of truth for the
  "existing" buildpack version, rather than the version from the
  buildpack registry. This allows the workflow to be used by classic
  buildpacks whose changelog/git tag versions are no longer in sync
  with the buildpack registry version. This also saves callers of this
  workflow from having to pass the specific name/ID that the buildpack
  uses on the registry.
- There's a new optional `custom_update_command` input, which can be
  used by the Ruby buildpack to update the version constant here:
  https://github.com/heroku/heroku-buildpack-ruby/blob/main/lib/language_pack/version.rb
  ...as well as perform the changelog directory rename.
- The PR description now includes a list of commits generated by
  git log, to make it easier to spot changes that have been forgotten
  in the changelog, as well as helping to identify when PRs are released
  thanks to the mention pings the prepare release PR will leave in the
  history of the original PRs.

I've intentionally kept the number of workflow inputs small, and not included
the ability to customise the runner or GitHub App details, since this workflow
is pretty team-specific, and unlikely to be used by others (in particular, the
overhead of having to set up your own GitHub App is pretty high), plus not
required for manual testing.

GUS-W-14894410.
    @edmorley
    edmorley committed Jan 26, 2024
    Configuration menu
    Copy the full SHA
    3ae60b4 View commit details
    Browse the repository at this point in the history

  2. Make actions/checkout fetch tags too 

    Since we need them to be able to determine the buildpack version
    @edmorley
    edmorley committed Jan 26, 2024
    Configuration menu
    Copy the full SHA
    a77acc2 View commit details
    Browse the repository at this point in the history

  3. Force a full clone to work around fetch-tags bug/limitation

    @edmorley
    edmorley committed Jan 26, 2024
    Configuration menu
    Copy the full SHA
    d611001 View commit details
    Browse the repository at this point in the history

  4. Tweak the generated PR description

    @edmorley
    edmorley committed Jan 26, 2024
    Configuration menu
    Copy the full SHA
    e7367f9 View commit details
    Browse the repository at this point in the history