Add stub script for compatibility-labelling PRs #22
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
rtyley
force-pushed
the
add-stub-workflow-script-for-compatibility-labelling
branch
7 times, most recently
from
d46a8ad to
fcd656d
Compare
|
Mock info: This PR Breaks Binary Compatibility when compared against most recent release 3.0.0. Details... |
This is a stub script that doesn't actually output true compatibility information, it's just a demonstration showing what kind of behaviour would be desirable. It's aiming to show the part 1 of the workflow described in scalacenter/sbt-version-policy#179: > **Keep devs aware of the compatibility of the PR they're working on** : When a PR is opened on a library repository, an automated workflow comments-on or labels the PR, making them aware that _"This PR breaks binary/source compatibility"_ - the information here would come from the `sbt-version-policy` plugin, but wouldn't require setting a `versionPolicyIntention` - it just establishes _what_ the level of compatibility the PR entails, so that the developer is aware. The assumption here is that whatever the developer is doing, they need to do it, and should just know the compatibility cost the PR is going to have (and possibly, though not necessarily, once informed they may be able to modify the PR to improve the compatibility). The script is written to add-and-remove labels as appropriate, if the required compatibility label (eg 'Breaks Binary Compatibility') wasn't already present, we assume this is new information and leave a detailed comment. In general, to reduce noise, we wouldn't necessarily want to add a new comment on every push, better to just tell the user how they can get this information by running locally...
rtyley
force-pushed
the
add-stub-workflow-script-for-compatibility-labelling
branch
from
fcd656d to
a72edce
Compare
|
Mock info: This PR Breaks Binary Compatibility when compared against most recent release 3.0.0. Details... |
rtyley
deleted the
add-stub-workflow-script-for-compatibility-labelling
branch
rtyley
commented
Nov 29, 2023
|
|
||
| pr_number=$1 | ||
|
|
||
| required_label="Breaks Binary Compatibility" |
There was a problem hiding this comment.
This would be the bit we need to run sbt-version-policy to get the correct value for!
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 is a stub script that doesn't actually output true compatibility information (that information will be coming with scalacenter/sbt-version-policy#184 & subsequent PRs), it's just a demonstration showing what kind of behaviour would be desirable.
It's aiming to mock-up part 1 of the workflow described in scalacenter/sbt-version-policy#179, ie:
The script is written to add-and-remove labels as appropriate, if the required compatibility label (eg 'Breaks Binary Compatibility') wasn't already present, we assume this is new information and leave a detailed comment. In general, to reduce noise, we wouldn't necessarily want to add a new comment on every push, better to just tell the user how they can get this information by running locally...