Use version from PR title when edited by end user #26

dgellow · 2023-09-04T17:51:08Z

To determine if the user edited the version from the PR title release-please does the following:

before building a release PR object, check if a PR already without a label exists for the release branch
if the PR has a label autorelease: custom version, use the version from the title and stop here
fetch the manifest from the release branch, get the version number for the relevant component
compare the version number with the PR title version number
if they don't match, we assume the end user edited the PR title version and use it
add a label autorelease: custom version to the PR
write a comment to the PR "The release version will not be automatically updated as it has been manually edited. If you want to use the calculated version remove the label autorelease: custom version"

For my tests I am using a github action like this one:

name: Handle release PR title edits
on:
  pull_request:
    types:
      - edited
      - unlabeled

jobs:
  update_pr_content:
    name: Update pull request content
    if: |
      (github.event.type == 'edited' && github.event.changes.title.from != github.event.pull_request.title) ||
      (github.event.type == 'unlabeled' && github.event.label.name == 'autorelease: custom version') &&
      github.event.pull_request.state == 'open' &&
      github.event.sender.login != 'stainless-bot' &&
      github.repository == 'stainless-sdks/sink-java-public'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: stainless-api/trigger-release-please@v1
        with:
          repo: ${{ github.event.repository.full_name }}
          stainless-api-key: ${{ secrets.STAINLESS_API_KEY }}

You can find an example of a release with a custom label here, and the release pull request here.

dgellow · 2023-09-04T17:51:54Z

The feature works, at least for the base strategy. Before merging I will add some unit tests to be sure all strategies have the same behaviour.

dgellow · 2023-09-04T18:59:45Z

Just thought about something simplifying the feature, instead of using a label we can check the current version from the release-please manifest from the release branch (before updating it of course): if it does not match the PR title, then the PR title has been edited.

Edit: PR description updated to match this logic

dgellow · 2023-09-04T19:34:03Z

Ok, I think that's way better. I need to test and write tests tomorrow.

RobertCraigie · 2023-09-05T08:58:36Z

if it does not match the PR title, then the PR title has been edited.

How does this work if the PR title has not been edited and another commit is pushed that would further increase the version number? e.g.

PR opened with a single patch commit, results in v3.0.1
The user edits the version to v3.0.1-beta
A feat commit is pushed, would result in v3.1.0
- At this time how do we know if v3.0.1 was set by the user or us?

Separately, is there any handling for the case where a commit is pushed after the user has edited the title? I think it could be quite nice to have a comment that the bot automatically updates that says something along the lines of:

Edited Notification

The release version will not be automatically updated as it has been manually edited.

Generated release version:
v3.4.5

dgellow · 2023-09-05T09:38:04Z

How does this work if the PR title has not been edited and another commit is pushed that would further increase the version number

This wouldn't be an issue, at the time we compare the version from the PR title to the version in the manifest the version bump didn't occur yet.

You can see it here:

https://github.com/stainless-api/release-please/pull/26/files#diff-580375fac796e3ac9eaac08ce5f7fbeffe915e755615d04103fa2899fcd437d5R303-R350

PR opened with a single patch commit, results in v3.0.1

The user edits the version to v3.0.1-beta

A feat commit is pushed, would result in v3.1.0
At this time how do we know if v3.0.1 was set by the user or us?

Separately, is there any handling for the case where a commit is pushed after the user has edited the title

Your example here seems to match the situation when another commit is pushed after an edit. That's something I thought about yesterday evening. The best solution I found is to add a label autorelease: custom version the first time we see a difference between the PR title version and the PR manifest version. If the label is set, just use the version from the title without any other check. If the user wants to go back to the calculated version, just remove the label?

Regarding the bot comment, that's a great idea, we can have release-please write a comment to the PR in addition to setting the label autorelease: custom version.

dgellow · 2023-09-05T14:08:13Z

I added PR comments for warnings and issues, and to communicate to the user how to the end user how they can change back to generated versions.

The different states can be seen on this PR:

marcel-stainless · 2023-09-05T14:34:22Z

src/strategies/base.ts

+
+:rotating_light: This Pull Request has the \`${DEFAULT_CUSTOM_VERSION_LABEL}\` label but the version number cannot be found in the title. Instead the generated version \`${newVersion}\` will be used.
+
+If you want to use a custom version be sure to use the semver format.


semver isn't something most people know what it means. Either explain or link to description?

Fair point. I actually started with a link to the semver spec but they aren't really user friendly. Would a link to something like this cheat sheet be more helpful? https://devhints.io/semver

Another option would be wikipedia? Not as user friendly: https://en.wikipedia.org/wiki/Software_versioning#Semantic_versioning

Cheat sheet link is good enough. Once it's clear what it means, users can investigate further, but the cheat sheet covers 99% (that's a very accurate madeup statistic)

src/strategies/base.ts

dgellow · 2023-09-05T15:44:48Z

Ok, now we have a test for this feature covering all the release type we are using: simple, node, python, and go 🐱.

When changing things related to the base strategy or from src/manifest.ts, I'm always afraid I'm breaking something for one of the plugin or strategy. And it's really time consuming if they have to be tested manually against actual repos.

src/strategies/base.ts

…dited' That makes it possible for an end user to control the version number number without having to rely on a commit with the footnote RELEASE-AS. The label can be easily added by a GitHub Action like this one: ```yaml name: Handle release PR edits on: pull_request: types: - edited jobs: update_pr_content: name: Update pull request content if: | github.event.pull_request.state == 'open' && github.event.changes.title.from != github.event.pull_request.title && github.event.sender.login != 'stainless-bot' # this is important to avoid infinite loops runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: actions/github-script@v6 with: script: | github.rest.issues.addLabels({ issue_number: context.issue.number, owner: context.repo.owner, repo: context.repo.repo, labels: ['autorelease: user edited'] # add the label }) - name: Then here run release-please - run: ... ```

… of label

…ecific strategies

dgellow marked this pull request as draft September 4, 2023 19:33

dgellow changed the title ~~Use version from PR title when labelled as user edited~~ Use version from PR title when edited by end ser Sep 5, 2023

dgellow changed the title ~~Use version from PR title when edited by end ser~~ Use version from PR title when edited by end user Sep 5, 2023

dgellow requested review from RobertCraigie and marcel-stainless September 5, 2023 14:11

dgellow marked this pull request as ready for review September 5, 2023 14:11

marcel-stainless reviewed Sep 5, 2023

View reviewed changes

src/strategies/base.ts Show resolved Hide resolved

marcel-stainless reviewed Sep 5, 2023

View reviewed changes

src/strategies/base.ts Show resolved Hide resolved

marcel-stainless reviewed Sep 5, 2023

View reviewed changes

src/strategies/base.ts Outdated Show resolved Hide resolved

marcel-stainless reviewed Sep 5, 2023

View reviewed changes

src/strategies/base.ts Show resolved Hide resolved

marcel-stainless approved these changes Sep 6, 2023

View reviewed changes

dgellow added 11 commits September 6, 2023 17:27

Determine PR title edit by looking at manifest from PR branch instead…

3de1ea8

… of label

Set 'autorelease: custom version' label and write helpful comment to PR

61a4552

fix: compile errors

32ef574

tests: fix compile errors

ab0b751

fix: make all existing tests pass

60b9596

tests: cover custom version via PR title edit

7259a3c

Warn user if version not in PR title

7394db3

tests: ensure setting version via PR title edit works for language sp…

773b4f0

…ecific strategies

Add link to semver cheat sheet

53aba16

Update snapshots

753c465

dgellow added 2 commits September 6, 2023 17:28

Improve warning message

71abec0

Fix test snapshots

6d150d2

dgellow force-pushed the sam/sta-2086-customer-should-have-way-to-control-a-release-version-number branch from eced66d to 6d150d2 Compare September 6, 2023 15:29

dgellow merged commit 99a4b0b into main Sep 6, 2023
7 checks passed

dgellow deleted the sam/sta-2086-customer-should-have-way-to-control-a-release-version-number branch September 6, 2023 15:33

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use version from PR title when edited by end user #26

Use version from PR title when edited by end user #26

dgellow commented Sep 4, 2023 •

edited

Loading

dgellow commented Sep 4, 2023 •

edited

Loading

dgellow commented Sep 4, 2023 •

edited

Loading

dgellow commented Sep 4, 2023

RobertCraigie commented Sep 5, 2023

Edited Notification

dgellow commented Sep 5, 2023 •

edited

Loading

dgellow commented Sep 5, 2023

marcel-stainless Sep 5, 2023

dgellow Sep 5, 2023

dgellow Sep 5, 2023

marcel-stainless Sep 5, 2023

dgellow commented Sep 5, 2023 •

edited

Loading


		:rotating_light: This Pull Request has the \`${DEFAULT_CUSTOM_VERSION_LABEL}\` label but the version number cannot be found in the title. Instead the generated version \`${newVersion}\` will be used.

		If you want to use a custom version be sure to use the semver format.

Use version from PR title when edited by end user #26

Use version from PR title when edited by end user #26

Conversation

dgellow commented Sep 4, 2023 • edited Loading

dgellow commented Sep 4, 2023 • edited Loading

dgellow commented Sep 4, 2023 • edited Loading

dgellow commented Sep 4, 2023

RobertCraigie commented Sep 5, 2023

Edited Notification

dgellow commented Sep 5, 2023 • edited Loading

dgellow commented Sep 5, 2023

marcel-stainless Sep 5, 2023

Choose a reason for hiding this comment

dgellow Sep 5, 2023

Choose a reason for hiding this comment

dgellow Sep 5, 2023

Choose a reason for hiding this comment

marcel-stainless Sep 5, 2023

Choose a reason for hiding this comment

dgellow commented Sep 5, 2023 • edited Loading

dgellow commented Sep 4, 2023 •

edited

Loading

dgellow commented Sep 4, 2023 •

edited

Loading

dgellow commented Sep 4, 2023 •

edited

Loading

dgellow commented Sep 5, 2023 •

edited

Loading

dgellow commented Sep 5, 2023 •

edited

Loading