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.

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

Make cherrypick_pr and open_pr scripts add version labels #6707

Merged
merged 1 commit into from
Mar 30, 2018

Conversation

tsg
Copy link
Contributor

@tsg tsg commented Mar 29, 2018

When cherry-picking, automatically reads the version from the target branch
and adds it as a label to the original PR.

When opening a new PR, automatically add the version label.

When cherry-picking, automatically reads the version from the target branch
and adds it as a label to the original PR.

When opening a new PR, automatically add the version label.
@ruflin ruflin merged commit a69f617 into elastic:master Mar 30, 2018
@ruflin
Copy link
Collaborator

ruflin commented Mar 30, 2018

One thing I worry with labels on each PR is what we had close to the 6.0 release. Some labels had v6.0.0-* label on them but the PR's did not make it in in time. Same for backports which don't get merged in time. In 6.0 the issue was the some people expected on the label that it will be in the release.

Not sure I have the full background on why we need labels with the version number it should go in on the PR.

@tsg
Copy link
Contributor Author

tsg commented Mar 30, 2018

@ruflin I see, ideally the label would be added at merge time instead of opening time, but that doesn't quite match our workflow (we merge with the green button). I'd say that compared to the grand time line, the difference is not to big, so there shouldn't be a ton of affected PRs, but it's something to keep in mind.

I suspect that we had issues before because the labels were completely manual.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants