-
Notifications
You must be signed in to change notification settings - Fork 209
Backport CLI refactor #968
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.
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
base: master
Are you sure you want to change the base?
Conversation
|
Closing and re-opening to trigger GH workflow... |
|
@NickDris We can avoid running GH workflow for labelling and reminding if we add an additional check in the workflow for the PR merge status. PRs can get closed without merge for various reasons, like here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Provided some comments below.
Reminder: As discussed 2 weeks ago, we might also need a different lookback mode that lists PRs based on merge time instead of update time, to be used ad-hoc with old PRs, but this can come in a follow-up PR.
| remove_clause="${{ github.event.inputs.remove == 'true' && '--remove' || '' }}" | ||
| python github_ci_tools/scripts/backport.py $pr_number_clause label --lookback-days ${{ github.event.inputs.lookback_days || '7' }} $remove_clause | ||
| python github_ci_tools/scripts/backport.py $pr_number_clause remind --pending-reminder-age-days ${{ github.event.inputs.pending_label_age_days || '14' }} $remove_clause | ||
| python github_ci_tools/scripts/backport.py $pr_number_clause remind --lookback-days ${{ github.event.inputs.lookback_days || '7' }} --pending-reminder-age-days ${{ github.event.inputs.pending_label_age_days || '14' }} $remove_clause |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Default lookback interval should be greater than reminder interval. This should also be validated in the tool when custom values are provided.
| "**How to proceed:**\n" | ||
| " - If it is intended for the current or next Elasticsearch release minor version, apply the corresponding version label.\n" | ||
| " - If it also supports past released versions, add those labels too.\n" | ||
| " - If it only targets a future version, wait until that version label exists and then add it.\n" | ||
| " (Each rally-tracks version label is created during the feature freeze of a new Elasticsearch branch).\n\n" | ||
| "Backporting entails: \n" | ||
| " - If it introduces functionality dependent on future versions, please wait until the relevant `vX.Y` label is created. In such cases, retain the `backport pending` label to enable periodic notifications.\n" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this can be simplified as per https://github.com/elastic/rally-teams/pull/111/files#r2660773161, i.e. there is no need to wait for vX.Y label because there should always be the next version label available.
backport.pybased on comments