Add a "Prepare release" workflow for classic buildpacks #184
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Jan 25, 2024
|
I tested this using heroku/heroku-buildpack-nodejs#1200. The PR it opened can be seen here: (The initial broken version title etc, was due to needing to add An example of using the |
colincasey
approved these changes
Jan 26, 2024
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.
Since we need them to be able to determine the buildpack version
edmorley
force-pushed
the
edmorley/classic-prepare-release
branch
from
f7266ce to
e7367f9
Compare
edmorley
added a commit
to heroku/heroku-buildpack-python
that referenced
this pull request
Jan 31, 2024
Switches to the new shared workflow added in: heroku/languages-github-actions#184 GUS-W-14900211.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
custom_update_commandinput, 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.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) - and is also not required for manual testing.
GUS-W-14894410.