Comments (5)
How about a hybrid (example adapted to my scenario):
I like it 👍
Running backport
For the initial implementation I'll enable this behaviour when running backport --pr
and backport --sha
and leave it out for backport --multiple
until I have a better idea of how it should behave.
@spalger I think you had a suggestion similar to this a long time ago. Would the hybrid approach work for your use case?
from backport.
@sqren Flippin' awesome! :) I will let you know if anything comes up (although tbh, it may take a while before I get my hands on it).
from backport.
Hey @ronkorving!
Sorry for the slow reply. I think is a great idea. I'm still not settled on a particular implementation but I'll sketch a rough idea of what I think. LMK if you have any suggestions to make.
versionLabelRegex
I'm proposing that to enable this feature the user must update .backportrc.json
with versionLabelRegex
:
{
"upstream": "elastic/kibana",
"branches": [{ "name": "7.x", "checked": true }, "7.7", "7.6"],
"versionLabelRegex": "^backport-(v\d+)$"
}
versionLabelRegex
is a regex that'll extract the target branch from labels. In this case the regex will match backport-v1
(v1), backport-v2
(v2) and so forth.
We can also make it an array if multiple matchers are necessary:
{
"upstream": "elastic/kibana",
"branches": [{ "name": "7.x", "checked": true }, "7.7", "7.6"],
"versionLabelRegexes": ["^backport-(v\d+)$"]
}
versionLabels
An alternative to versionLabelRegex
is versionLabels
, where labels are directly mapped to a branch:
{
"upstream": "elastic/kibana",
"branches": [{ "name": "7.x", "checked": true }, "7.7", "7.6"],
"versionLabels": {
"backport-v1": "v1",
"backport-v2": "v2",
"custom-label-v3": "v3",
}
}
This approach allows for more flexibility but is also more verbose.
Do you have any preferences for versionLabelRegex
or versionLabels
?
Running backport
Both approaches will work intuitively when backporting individual PRs like backport --pr 123
: if one or more applicable labels are found, the PR will be backported accordingly without asking the user any additional questions.
But what should happen if the user runs something like backport --multiple
? They will now be prompted to select one or more commits to backport, which might not all have version labels.
The user could select a commit which does have version labels, and a commit which doesn't.
In that case should the user then be prompted to select branches to backport to? And should that selection override the version labels or only apply to the commit that doesn't have version labels?
Is it possible that someone might want to override the label logic, and backport a commit to other branches?
LMK if it makes sense and whether you have any opinion on this matter.
from backport.
Hey, thanks for the extensive response and proposals.
Configuration
About versionLabelRegex
vs versionLabels
, I think a hybrid might be superior. I'll give a real world example from a project I'm working on. My master branches are v1-master
, v2-master
, v2.1-master
, etc. If I want a label v1
, the regexp approach seems tricky, because I cannot append -master
in the result. So I would have to label v1-master
. This is not the end of the world of course, but now is the time to be nitpicky I guess, before things get built.
versionLabels
are a solution, but they are not just verbose, they also require upkeep.
How about a hybrid (example adapted to my scenario):
{
"versionLabels": {
"some-special-branch": "some-special-label",
"v([0-9]+)-master": "v$1"
}
}
This allows both regular expression replacement, and simple mapping to co-exist.
The $1
syntax is based on how String.prototype.replace
works. This does of course make the $
symbol a special character, but I imagine that's worth it. One could always allow $$
to mean a literal $
if we really need it.
Running backport
To be honest, I don't have strong opinions or ideas on this at this time, especially as I haven't yet really used --multiple yet. I think conflicts should prompt the user to act. If at that point, the labels can be displayed, and the choice can be made manually (incl. the choice to abort), I think it should be fine?
from backport.
@ronkorving This has been released in v5.2.0. I ended up naming the option branchLabelMapping
. You can find the documentation here.
LMK if it works like it should. If you have any other suggestions we can iterate on it.
from backport.
Related Issues (20)
- Can this be tool used with GitLab? HOT 1
- Unexpected token . HOT 5
- v8.9.7 - Cannot read properties of undefined HOT 1
- Add support for dynamic `sourcePRLabels`
- Provide the upstream PR title as a template variable to build the backported PRs title HOT 4
- Option to copy labels from target to source HOT 5
- Workflow permission is required for pushing changes
- List of releases is out of date HOT 1
- `No target branches found for this PR` error HOT 7
- Query `CommitsByAuthor` gets 502 error in Github response when using large `maxNumber` HOT 5
- Upgrade Axios to dismiss security alerts
- Whatever I do i get a "branch is invalid or doesn't exist" HOT 8
- Support Azure DevOps HOT 7
- [Feature Request]: support draft PRs
- `sourcePullRequest.title` contains escaped characters HOT 4
- Allow setting target branches by branch name pattern
- t HOT 1
- Hitting a null object error sporadically HOT 6
- providing terminal editor during conflicts hangs the process HOT 1
- Backports opened against wrong parent PR
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from backport.