Add support for adding and removing labels from an issue

[andrewnicols]

mdk tracker --add-labels cime
mdk tracker --add-labels cime triaged
mdk tracker --remove-labels triaged
mdk tracker --remove-labels moronic --add-labels triaged

[danpoltawski]

I find mdk tracker a curious fit for mdk TBH - you can't triage an issue without looking at the data on the issue, so what labels would this be for adding on a single issue, where it makes more sense to do it on the CLI?

So, imagining the main reason you created this feature was to add the cime label- don't go down this route. We can add a script for mdk (see MDLSITE-2715) which will directly start a jenkins job to run the prechecker and it won't cause tracker noise and will also get the results happening instantly.

The only caveat to that, is that we will need to pass out the tokens for access to the pre-checker on an individual basis.

[andrewnicols]

Ooh - I like the look of MDLSITE-2715. Primarily, I was looking at it for the CIME label, but if we can do this in a different, less noisy way, then that would be great too. Having the ability to do it this way would still be good for those without a jenkins key.

My workflow is often such that:

git add .; git commit --amend mdk push -f -t ; mdk backport -v 28 27 -p -f -t ; mdk tracker --add-labels cime Ideally I'd like to be able to make the mdk backport or mdk push do it all in one, e.g. mdk push -f -t --cime mdk backport -v 28 27 -p -f -t --cime Andrew

[andrewnicols]

Another use-case I have is when doing peer reviews. As part of an old peer review, I often rebase against master (or update in some fashion) because the previous cibot run has failed:

mdk pr 12345
git rebase origin/mater
mdk push -f -t --cime

I want the results to be public to the user in these cases. The noise is acceptable in that kind of situation as I will refer to it again later.

[FMCorz]

I'm not too much of a fan of --cime, I find that a bit too specific to the tracker. In fact, I would rather split some commands, there are already some weird combinations and others missing. Sometimes I think it is not that bad having to type a second command, or creating custom scripts that push and add labels for you for instance.

I keep on thinking that MDK should support plugins, which it kind of does already if you import the mdk package, where you could do whatever combination of magic you want. This, of course, requires a better abstraction of some APIs.

[andrewnicols]

Thanks Fred,

The reason that I like the idea of combining commands like this is to avoid spamming people. If we can combine multiple changes into a single update to Jira, then we massively reduce the number of notifications that they receive.

At present, to do: mdk push -t && mdk backport -v 28 27 -p -t we generate 3 notifications. I'd love to be able to not add a 4th. If I also add mdk tracker --comment to the mix to say what I've done, that's then adding a further commit.

[FMCorz]

I agree, I am not quite happy with the way it works now either. Backport could itself buffer some updates but I never got to it. Also I feel that having mdk tracker --update-branches 27 28 master would not actually be that bad. As an example, git fetch then merge, or git pull. Basically they made a shortcut but initially you had to do both separately. Maybe MDK push could evolve in something different though I like being able to push straight to github, I firstly made that command because I was too lazy (and forgetful) to type the name of my branch.

[andrewnicols]

Testing example:

 mdk fix 48550
 mdk tracker --remove-labels foo bar
 mdk tracker --add-labels foo
 mdk tracker --remove-labels foo bar
 mdk tracker --add-labels foo bar
 mdk tracker --remove-labels foo
 mdk tracker --remove-labels bar

[FMCorz]

Thanks Andrew, I've merged and refactored a bit. I have also added a commit to prevent the usage of both labels triaged and triaging in progress.