-
Notifications
You must be signed in to change notification settings - Fork 56
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
Per project configuration #27
Comments
I imagine the config would look something like: {
"name": "elastic/kibana",
"versions": ["6.x", "6.1", "6.0"],
"labels": ["backport"]
} Is that what you had in mind? It will only be picked up, if |
I would probably change the config resolution to function more like:
{
"accessToken": "...",
"username": "..."
}
{
"upstream": "elastic/kibana",
"origin": "{username}/kibana",
"own": true,
"multiple": true,
"versions": ["6.x", "6.0", "5.6", "5.5", "5.4"],
"labels": ["backport"]
} I don't think there's any reason the backport tool needs to support overrides or per-project config in the |
That makes sense! I also prefer the naming you use, eg. A couple of thoughts:
That's just my impression of how people work but it would be great if we can have less user-specific options, and users don't have to think. |
Maybe
as you said. That way users actively have to override the project settings, if they really want to, but it'll Just Work for them if they don't. |
My thinking is: if I add |
Personally, I think if a project specifically wants certain configurations, individual users shouldn't be able to override them. Otherwise we can't reliably ensure that our automation is doing what we need/want it to do. |
@sqren I assume you're thinking about options like I guess part of my design includes not specifying project-specific configuration in the |
Yeah, we definitely want to get rid of that. That should also happen automatically with the addition of a
Yes, it was exactly those I meant. I'll try removing all the project specific stuff, and move it to a |
@spalger I just talked to @vanjacosic and he had a good point about backport labels. Currently his config looks like: {
"repositories": [
{
"name": "elastic/kibana",
"versions": ["6.x", "6.1"],
"labels": ["apm", "backport"]
}
]
} As I understand your suggestion, he would only be able to add custom labels (like "apm")
Do you see any good ways to support this use-case? |
As far as I know he's the only person doing this - is it necessary? The backports link to a canonical issue that has the relevant feature/team labels on it. The backport label itself is really just there for filtering and automation. |
That's an interesting idea, and seems like a reasonable feature to provide. Maybe the global config could accept an array of labels and apply those without filtering by project, or perhaps we could change the per-project overrides in the global config to be selected with a path of some sort rather than the current algo. Something like this perhaps:
Alternatively, we could add |
@spalger @epixa There is an open PR #29 and I've published a beta version that you can install if you want to try it out: With the beta you can add the following {
"upstream": "elastic/kibana",
"versions": ["6.x", "6.1", "6.0", "5.6", "5.5", "5.4"],
// optional
"labels": ["backport"],
"own": true,
"multipleCommits": false,
"multipleVersions": true
} and simplify your global config {
"accessToken": "...",
"username": "..."
} |
Btw. I'm thinking about renaming "versions" to "branches", since that's really what they are. Any objections? |
Closed by #29 |
The config file currently lives in
~/.backport
, which is fine, but it would be awesome if we could check-in the config for a project (like the repo location, branches, etc)The text was updated successfully, but these errors were encountered: