sorenlouv/backport

A simple CLI tool that automates the process of backporting commits on a GitHub repo

backport's Issues

Add `--rebase <pull request number>` option

It should be easier to rebase PRs than it is today.

Usage:

backport --rebase 15

Above command should attempt to rebase the head branch (head.ref) with the base branch (base.ref) for pull request number 15 - upstream should be read from .backportrc.json or passed in as CLI arg.

Add `backport` label on repos where it exists

It's really useful for glancing at a list of PRs or auditing PRs to be able to filter away any PR that has a backport label, so it'd be great if this tool added that label automatically to all backport PRs.

Add integration test that execute real git commands

Currently none of the git functionality is properly tested. The Git commands should be executed in different versions of Git, eg. 2.13 and above (up to latest 2.19.x)

For the integration tests, a local repository will act as a remote repo:

git init --bare ~/repos/myproject.git
cd /path/to/existing/repo
git remote add origin ~/repos/myproject.git
git push origin master

https://stackoverflow.com/questions/10603671/how-to-add-a-local-repo-and-treat-it-as-a-remote-repo

Get branch ordered by commit date
git branch --sort=-committerdate
https://stackoverflow.com/questions/5188320/how-can-i-get-a-list-of-git-branches-ordered-by-most-recent-commit/5188364#5188364

Startup check should verify that user has compatible Git version.

Allow editor to be auto-opened for conflicts

When a merge conflict arises, backport asks the user to resolve conflicts at the repo path, similar to:

Backporting #28692 to 6.6
✔ Pulling latest changes
✖ Cherry-picking failed. Please resolve conflicts in: /Users/larry/.backport/repositories/elastic/kibana
? Press enter when you have commited all changes Yes
✔ Pushing branch legrego:backport/6.6/pr-28692
✔ Creating pull request
View pull request: https://github.com/elastic/kibana/pull/28701

It would be awesome if we could optionally configure backport to open an editor at the repo path. For my specific setup, I would like backport to execute code ${repoPath} so that VS Code automatically opens a new window to the repository path. If automatically opening the editor would be too aggressive, we could have another prompt similar to:

Backporting #28692 to 6.6
✔ Pulling latest changes
✖ Cherry-picking failed. Please resolve conflicts in: /Users/larry/.backport/repositories/elastic/kibana
? Open editor to resolve conflicts [Y/n]
? Press enter when you have commited all changes Yes
✔ Pushing branch legrego:backport/6.6/pr-28692
✔ Creating pull request
View pull request: https://github.com/elastic/kibana/pull/28701

Add `--reset-author` flag

When amending a commit you can use the --reset-author flag to redefine the author of the commits as yourself. This is generally not recommended, but is desired for backporting automated commits like those done by renovate (mostly so that CLA checking works).

Add options to specify config file from command line

GitHub API `access_token` query parameter is deprecated

Received an email from GitHub today after using backport to create a PR in elastic/kibana:

your personal access token (sqren/backport) using axios/0.19.0 was used as part of a query parameter to access an endpoint through the GitHub API
[...]
Please use the Authorization HTTP header instead, as using the access_token query parameter is deprecated.
[...]
Visit https://developer.github.com/changes/2019-11-05-deprecated-passwords-and-authorizations-api/#authenticating-using-query-parameters for more information.

Global config.json used to store access_token value.

Update message about conflict resolution

When a conflicts occurs currently the message currently says:

✖ Cherry-picking failed. Please resolve conflicts in: /Users/sqren/.backport/repositories/elastic/kibana
? Press enter when you have commited all changes Yes

This should be updated to:

✖ Cherry-picking failed. Conflicts in: /Users/sqren/.backport/repositories/elastic/kibana must be resolved.

Run `git cherry-pick --continue` when all conflicts have been resolved and staged. 

? Press <enter> when you are have completed above steps

An in-range update of @types/node is breaking the build 🚨

The devDependency @types/node was updated from 10.12.8 to 10.12.9.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

• ❌ continuous-integration/travis-ci/push: The Travis CI build could not complete due to an error (Details).

---

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Add the ability to forwardport a change

Occasionally I do work on a non-master branch and want to forwardport a PR to the master branch, however, even if I manually specify the SHA and branch:

~/es/elasticsearch (git) 0f312c8b  7.x [origin/7.x] (2 stashed)
» backport --sha 0f312c8b381fe19b69964f1ef677c9c46ed844b7 --branch master       
✖ Loading commit "0f312c8b"
No commit found on master with sha "0f312c8b381fe19b69964f1ef677c9c46ed844b7"

It appears to look for the sha on the master branch instead of 7.x.

It'd be great to be able to forwardport though!

backport -v and backport --version doesn't do the same

In backport --help it's listed:

  -v, --version                 Show version number                                                            [boolean]

However, only backport --version shows the version number. backport -v just launches the interactive picker. It might turn on verbose instead?

Add option for specifying extra content in the PR description

There are some comments that we add to the PR description and they affect the types of checks that are run immediately on the PR. This tool is so fast that I can't get into the backport PRs and add those strings (like "skip ci") before the (unnecessary) tests start running.

Support ssh keys with passphrase applied

backport does not appear to support ssh keys that are protected by a passphrase. The process hangs indefinitely when trying to clone the repository. If I recreate my key without a passphrase applied, then the backport works perfectly.

I'm guessing that the git client is waiting for the passphrase to be entered via stdin, but backport doesn't expose/allow that to be entered via command line. It would be nice if we could enable this support, so users can protect their keys if they so choose.

System Config:

• OS: macOS High Sierra 10.13.3
• Git Client: 2.14.3 (Apple Git-98)

Add instructions for how to run via Docker when someone asks for it

Removed the Docker section from the readme because no-one seems to use it

---

Run via Docker

If you don't have Node.js or git installed locally, you can run backport via Docker.

Click to expand

The easiest way is to add the following snippet to your bash profile:

backport() {
    BACKPORT_CONFIG_DIR=~/.backport
    GIT_CONFIG_FILE=~/.gitconfig

    docker run -it --rm -v $(pwd):/app:ro -v $BACKPORT_CONFIG_DIR:/root/.backport -v $GIT_CONFIG_FILE:/etc/gitconfig sqren/backport "$@"
}

Where:

• BACKPORT_CONFIG_DIR: This can be ANY empty folder on your local machine. Upon running the docker container for the first time, a config.json will be created automatically. This must be filled out with username and accessToken or these must be passed as CLI arguments: backport --username <username> --accessToken <accessToken>
• GIT_CONFIG_FILE: Must point to a local .gitconfig file that contains the user's name and email.

You can now use backport as if it was installed on the host machine.

Add ability to define custom Github URL

• Right now the Github API Urls are hard coded for public Github.
• It would be nice to be able to define a custom Github API Url for consumers using Github Enterprise.

Better handling of network issues

Currently there is no attempt to handle network issues. Things that could be done:

• Not failing silently (happens sometimes)
• Better error messages instead of dumping a stacktrace
• Retrying

[Enhancement] Prevent accidental push from the backport repo

Currently, backport clones the tracking repo under the remote name origin and the fork repo under the Github username of the user. In many dev environments, origin is used as the remote name for the user's fork.

Based on the number of backport branches in Kibana, it looks like developers are accidentally doing the equivalent of git push origin <branchname>, possibly while working in the tool's private repo to resolve merge conflicts.

I like this suggestion from @timroes:

The backport tool should create a pre-push hook in that backport repo, that will prevent pushing if a specific environment variable isn't set (that it sets when itself pushes) and then just prints a warning: Don't push manually here, just follow instructions of the backport tool please

Make it clear that by default only own commits are displayed

There is some confusion around backporting other people's commits. By default backport will only show a users own commits.

Crash on large fetch

Recently Kibana had a huge pull request merge. Running backport afterwards resulted in this stack trace. Subsequent running kinda got it back in order.

$ ./node_modules/.bin/backport 
? Select commit to backport Bumped Vega lib version to 3.3.1 (#17829)
? Select branch to backport to 6.x
Backporting #17829 to 6.x
✖ Pulling latest changes
{ Error: stdout maxBuffer exceeded
    at Socket.<anonymous> (child_process.js:252:14)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:188:7)
    at readableAddChunk (_stream_readable.js:176:18)
    at Socket.Readable.push (_stream_readable.js:134:10)
    at Pipe.onread (net.js:547:20)
  cmd: 'git reset --hard && git clean -d --force && git checkout master && git pull origin master' }

An in-range update of axios-mock-adapter is breaking the build 🚨

The devDependency axios-mock-adapter was updated from 1.15.0 to 1.16.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

axios-mock-adapter is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

• ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).

---

Commits

The new version differs by 24 commits.

• 74d9b56 1.16.0
• 9836b59 Merge pull request #182 from Backfighter/patch-1
• 677f1f1 Add history to typescript definition
• 027a821 Test list verb, add type definitions
• 221f61a Add test for interceptors
• ae6d725 Merge pull request #162 from kodie/master
• 355ae84 Update dependencies
• 4e4c64b Merge pull request #179 from jonasps/regex-example
• d5ea3b6 Merge pull request #174 from jan-molak/master
• e4d4fed Merge pull request #178 from LukeeeeBennett/patch-1
• 850b225 Update README.md
• 9be280d Document history property in README.md
• 592b400 Updated type definitions to include the optional headers matcher in onGet, onPost, onPatch, etc. See #70
• 8681af9 Merge pull request #167 from EdwardDrapkin/master
• 3aaa145 Add list as an http verb

There are 24 commits in total.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

An in-range update of @types/ora is breaking the build 🚨

The devDependency @types/ora was updated from 3.1.0 to 3.2.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/ora is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

• ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).

---

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Verify access token validity and scopes on startup

Currently if the access token is invalid or doesn't have the correct scopes, the application will crash with this error:

Error: Command failed: git push johndoe backport/7.x/pr-12345:backport/7.x/pr-12345 --force
remote: Permission to johndoe/kibana.git denied to johndoe.
fatal: unable to access 'https://[email protected]/johndoe/kibana.git/': The requested URL returned error: 403

To handle this situation more gracefully the application should initially verify that the validity and scopes of the access token.
If the access token is invalid it should exit with a helpful error message.

fetch(`https://api.github.com/${owner}/${repoName}?access_token=${accessToken}`, {
  method: 'HEAD'
})

feature request: use source PR labels to pick branches to backport to

First off: awesome project! Thank you for your work.

I have a feature request, and would love to hear your thoughts. It would be really nice if it were possible to create some feature PR that will later need to be backported. Often you know beforehand where it should be backported to. One could use GitHub labels to mark that all PRs with label backport-v1 should later be backported to the v1 branch. If a label system like that is applied, running backport --pr 123 could read those labels and preselect all the right branches.

Being able to determine ahead of time where we backport to would really improve our workflow. I'm guessing we may not be alone in that.

An in-range update of @types/jest is breaking the build 🚨

The devDependency @types/jest was updated from 23.3.2 to 23.3.3.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/jest is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

• ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).

---

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Option to specify repoName and branch from command line

It is currently only possible to specify repoName through a local config, and branch interactively.
Users in a non-interactive environment cannot use arrows, so command line options should be available.

Migrate to GraphQL API

backport currently uses Github's v3 REST api. It might be possible to improve the response time of API requests by switching to v4 Graphql API, since only necessary data is sent over the wire

Prefix backport PRs with [<branch>] rather than [backport]

Having some sort of meaningful indication on a PR that it is a backport is helpful, but it doesn't necessarily need to be the word "backport" in the title. The convention of putting the target backport branch as a prefix on the backport PR title would still be recognized by people using this tool frequently, and the backport label could be the thing that says the word "backport" in case people want that.

Using the branch prefix really helps with auditing PRs to ensure that they were properly backported since you'd have all of the necessary information you need about the PRs right in the linkbacks in the original PR.

For example, these linked backport PRs would be much more useful if they instead began with their target branch:

Add ability to define a custom PR title

• This would be especially helpful for those using standard version who want the commit messages to be in the front of the commit message for the prefix notation
• Allow consumer access to base branch name and commit messages strings

Fails to backport if a branch named "backport" exists on remote

If you already have a branch named backport in the remote repo, the backport tool fill fail to make the backport PR.

I think the issue is that all backport PR's live in branches that starts with backport/.... I think the technical reason for the issue is that if you make a branch named foo this is just a file on disk stored at .git/refs/heads/foo. But if you make a branch named foo/bar, git will attempt to store it on disk at .git/refs/heads/foo/bar. But if there's already a file named foo there, it can't also create a directory named foo - hence why backport fails if there's a branch named backport.

Add options for specifying a list of sha's

It's currently possible to specify a specific commit to backport by using backport --sha <commit>. It should be possible to specify several commit sha's like backport --sha <commit1>,<commit2>.

Warn user if they don't have commit access

You can create a backport if you don't have commit access to a repo you've forked. Check the user's commit access to the upstream repo to warn them that it might not work as they expect.

I could be wrong, but I think it does not do this now.

When access ssh for first time, prompt to add fingerprint to known hosts

Backport tool uses ssh which prompted me to accept the new fingerprint and add it to my known hosts which paused/waited because stderr/stdout is not properly being displayed.

It should fail or prompt me to accept the fingerprint?

@spalger

A way to select commits based on PRs labels?

Hello,
Thank you for this awesome utility. It will definitly save me a lot of time.

I want to pre-select multiple commits based on the labels of the original PR. Is that possible to day?

There seems to be a --backportCreatedLabels but it does not seem to do anything.

Disable fork-mode

backport expects that the user has their own fork of the repo, and will therefore attempt to always only push branches to the fork.

Not all orgs use forks and it should be possible to create backport branches on the origin repo.

Suggestion
Disable fork mode in .backportrc.json:

{
  "upstream": "elastic/kibana",
  "branches": [{ "name": "7.x", "checked": true }, "7.3", "7.2"],
  "fork": false
}

[conflicts] Ensure repo is clean before push/pr phase

When conflicts are found during a cherry-pick the backport tool pauses, but it doesn't verify the user input when they say that the conflict has been resolved. If the conflict has been resolved but the cherry-pick has not been --continue'd an incomplete pr is pushed to the user's fork and pull requested.

I think that when the user answers "Have you solved the merge conflict?" with Y the backport tool should verify that the repo is not dirty and that there is no cherry-pick/rebase/merge pending.

It would also be nice if the "Have you solved the merge conflict?" message offered a ? input that described the steps the user should take in more detail, and offered these instructions to the user in case they have not handled conflicts in a backport before.

When backporting by sha, ensure that the commit is in master

Find commit in default branch (mostly master):

GET https://api.github.com/search/commits?q=hash:<sha>%20repo:<owner/repoName>&per_page=1&access_token=<accessToken>

Hangs after creating the pull-request

Running backport and selecting the commits and branch interactively hangs after the pull-request have been created. I have to ctrl+c in order to continue.

My config.json only has accessToken and username and the backport.log file ends with Adding label 'backport' to #8779

Some strangeness where a branch called 6.0 is attempted to be used as 6

⋊> ~ backport --sha 1f25a0bd31f86ddc7231e8a302321cd2c4a525e6 --branch 6.0 --upstream elastic/elasticsearch
? Select commit [Docs] Add example for updating meta field (#35893)
Backporting #35893 to 6
✖ Pulling latest changes
The branch "6"  is invalid or doesn't exist

and if using quotes...

⋊> ~ backport --sha 1f25a0bd31f86ddc7231e8a302321cd2c4a525e6 --branch "6.0" --upstream elastic/elasticsearch
? Select commit [Docs] Add example for updating meta field (#35893)
Backporting #35893 to 6
✖ Pulling latest changes
The branch "6"  is invalid or doesn't exist

Add option to dynamically specify a list of labels to be added to created PRs

I see adding labels is possible by using the config file but it would be neat to be able to specify labels at runtime with a parameter.
It might also be good to have two modes to do this, one for replacing the label list (eg only using the provided list) and another for providing additional labels to any already defined in the config file.

Per project configuration

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)

Add option to specify number of commits to be listed

Version 10 of node.js has been released

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml
• Replaced the old Node.js version in your .nvmrc with the new one
• The new Node.js version is in-range for the engines in 1 of your package.json files, so that was left alone

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

More information on this issue

Greenkeeper has checked the engines key in any package.json file, the .nvmrc file, and the .travis.yml file, if present.

• engines was only updated if it defined a single version, not a range.
• .nvmrc was updated to Node.js 10
• .travis.yml was only changed if there was a root-level node_js that didn’t already include Node.js 10, such as node or lts/*. In this case, the new version was appended to the list. We didn’t touch job or matrix configurations because these tend to be quite specific and complex, and it’s difficult to infer what the intentions were.

For many simpler .travis.yml configurations, this PR should suffice as-is, but depending on what you’re doing it may require additional work or may not be applicable at all. We’re also aware that you may have good reasons to not update to Node.js 10, which is why this was sent as an issue and not a pull request. Feel free to delete it without comment, I’m a humble robot and won’t feel rejected 🤖

---

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Add empty state messages

If there are no commits, the display will just be blank. It should show an empty state message "No commits to list".

Drop support for Node 6

Node 6 will enter maintenance mode in April 2018. Some dependencies (eg. Joi) have already dropped support for Node 6, which means backport can't update to the newest version until we do the same.

Expecting to drop support somewhere in April 2018. This will happen in a major version bump.

Opportunities when dropping Node 6 (and thus targeting Node 8):

• Update Joi to latest version (currently stuck on 12.0.0)
• Replace es6-promisify with util.promisify
• Replace Object.assign with object spread
• replace .then chains with async/await

Add startup check to ensure ssh to Github works

backport relies on ssh access to Github. There are a couple of scenarios where the git commands will fail due to issues with ssh. Instead of handling these midway in the backporting process, the user should be told upfront about configuration issues, and how to fix them.

Issues that backport should warn about:

• github.com is not in "known_hosts" file.
  If the user has never accessed github over ssh, Github's IP-address will not be trusted, and will prompt the user. Instead of handling the prompt inside backport the user should abort backport and run something like ssh -T [email protected] which will bring up the prompt.

  ssh-keygen -H -F github.com can be used to detect if github.com is added to "known_hosts".

• ssh key is protected with a passphrase, and has not been added to ssh-agent
  If the user has a passphrase on their ssh key, and are not using ssh-agent, backport will choke on this prompt:
  Enter passphrase for key '/Users/sqren/.ssh/id_rsa':

  Instead of trying to handle the prompt, and the back/forth input exchange (I really don't want to touch the user's passphrase) we should abort backport and tell the user how to add their ssh key to ssh-agent. Possible by linking to Github's excellent docs: https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/#adding-your-ssh-key-to-the-ssh-agent

  I still don't know how to detect if the user has a key with a passphrase, that has not been added to ssh-agent. It's possible to detect whether the user has added a key to ssh-agent with ssh-add -l.

Update
It might be possible to check for both cases by simply trying to SSH to Github:

ssh -oBatchMode=yes -T [email protected]

• If everything is fine, the process will exit with status code 1 and print "Hi {username}! You've successfully authenticated, but GitHub does not provide shell access."
• If github.com is not in known_hosts it will exit with 255 and print "Host key verification failed."
  Solution: ssh -T [email protected]
• if the key has a passphrase which is not stored in ssh-agent it will exit with 255 and print "[email protected]: Permission denied (publickey)."
  Solution: https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/#adding-your-ssh-key-to-the-ssh-agent

Caveats: this has a noticeable delay, and shouldn't be done on every startup.

• Only check the very first time backport is executed (would require state to be stored somewhere)
• Only check whenever a repo is setup (cloned). Doesn't require additional state, and happens very rarely.

Debugging workflow

List all keys

ssh-add -l

Remove all keys from ssh-agent:

ssh-add -D

Add key to ssh agent:

ssh-add -K ~/.ssh/id_rsa

Verify ssh-agent

ssh -oBatchMode=yes -T [email protected]

credential.helper

# disable
git config --unset credential.helper

# enable
git config credential.helper store

Global config should automatically be created post-install

Right now ~/.backport/config.json is created when the user runs backport the first time.
It would be better if it was created after install, so the user can go straight ahead, and add their credentials.

{
  "scripts": {
    "postinstall": "scripts/postinstall.js",
  }
}

Cannot read property 'target' of null

I've probably misconfigured something, but when I simply run backport --verbose it fails with:

✖ Loading commits...
TypeError: Cannot read property 'target' of null
    at Object.fetchCommitsByAuthor (/Users/rkorving/Projects/redacted/node_modules/backport/dist/services/github/fetchCommitsByAuthor.js:95:31)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:189:7)

which translates to https://github.com/sqren/backport/blob/2a100ccfe1c339ead0f3c985e920e19bcd4d11f3/src/services/github/fetchCommitsByAuthor.ts#L108

When I look in the verbose log, the last steps I see are:

2019-10-08T07:56:48.850Z verbose: {
  "repoOwner": "redacted-but-correct",
  "repoName": "redacted-but-correct",
  "commitsCount": 10,
  "authorId": "redacted-but-some-correct-looking-hash",
  "historyPath": null
}
2019-10-08T07:56:49.303Z verbose: {
  "data": {
    "repository": {
      "ref": null
    }
  }
}

I use github.com, a private repo, and I know I have commits in its history.
I enabled these scopes when creating a token for it:

My project's .backportrc.json file:

{
  "upstream": "myorg/myrepo",
  "branches": ["v0-master"],
  "all": true,
  "fork": true,
  "multipleCommits": true,
  "multipleBranches": true,
  "labels": ["backport"]
}

(I've tried with "all": false as well, but same result)

Backport v4.7.3.

Allow commits with multiple parents

Issue

Some folks are fans of the ol' squash-and-merge, which makes backporting easy since it's only one commit. For those who aren't, a similar way to do this is backporting the merge commit itself. Since merge commits have multiple parents, the cherry-pick phase fails. In order to cherry-pick correctly, one would need to use the --mainline, -m flag to specify which parent commit to use for the mainline or base branch. In most cases, this is the first parent: git cherry-pick -m 1 <sha>, but it would be nice to allow a user to specify that option.

Proposal

Add a --mainline flag to allow backporting commits with multiple parents, such as merge commits.

Considerations for implementation

Could use 1 as the default since it's the most common case and will work even with commits with only one parent. There's also an argument to be made that null should be the default which would allow git cherry-pick to fail like it currently does unless the user specifies the option.

Add `backported` label to PRs when running the backport tool

How would you feel about supporting configuration that adds a label like backported to a PR once the backport PRs have been created? It's a little misleading because the backport PRs haven't been merged, but it's also a good indicator as PRs have a lot more visibility (usually PRs don't go unmerged for too long) and the status of each backport PR is usually listed at the bottom of the history for the source PR...

Thoughts?

cc @FrankHassanabad @spong

Automatically resolve conflicts in yarn.lock

It could be nice if backport automatically handled conflicts in yarn.lock files by running yarn (or a custom command like yarn kbn bootstrap) and then git commit --no-edit when it exits successfully.