Opt repo into "copy-labels-linked" automation action

[mbestavros]

pull-request-responsibility, the repo providing rust-keylime with its PR review cycle automation, is getting some new features!

1. Auto-merge -- if all required merge criteria is met (ex. approval from x reviewers with write access, tests passing, no conflicts), PRs will automatically be merged

2. Copy linked labels -- if you link a PR to an issue, automatically copy any labels on the issue over to the PR. For example, if issue Bug: CI Build Failure #123 has the label "enhancement" and PR Bug: Error handling needed for config  #124 is linked to Bug: CI Build Failure #123 (by using "Resolves #xyz"), PR Bug: Error handling needed for config  #124 will automatically be tagged as "enhancement" as well

These new actions will be enabled by default soon. However, if one or both of these aren't appropriate for rust-keylime, this patch will opt the repo out of both. Feel free to close if both sound good or merge if there are concerns with the above actions (or request changes if you only want to allow one).

I've changed the automation action's behavior from opt-out to opt-in. This PR now opts rust-keylime into the new copy-labels-linked action as well as existing actions, while not enabling auto-merge (per @mpeters' concerns).

[lkatalin]

I think those enhancements both sound good; what do others think?

[ashcrow]

I agree @lkatalin. They sound good to me too.

[mpeters]

I like #2 but #1 I'm less inclined toward. As a developer if I have multiple PRs in flight I like having some control over which order they merge in to make my life easier dealing with conflicts/rebases/etc vs just what order their criteria are met.

[mpeters]

Also, is there a way to make it opt-in vs opt-out? I don't like the idea of the upstream tool doing things to our repo we haven't explicitly enabled

[lukehinds]

I like #2 but #1 I'm less inclined toward. As a developer if I have multiple PRs in flight I like having some control over which order they merge in to make my life easier dealing with conflicts/rebases/etc vs just what order their criteria are met.

That is a valid case (for # 1), could we use some sort of 'hold' string that can be used to park a patch. You can see this in action on the coreos repo (by our own @ashcrow even) coreos/coreos-assembler#1790 (comment)

If searching for strings is a headache, perhaps a label 'no-auto-commit'

[mpeters]

That is a valid case (for # 1), could we use some sort of 'hold' string that can be used to park a patch. You can see this in action on the coreos repo (by our own @ashcrow even) coreos/coreos-assembler#1790 (comment)

If searching for strings is a headache, perhaps a label 'no-auto-commit'

I like these ideas and if Mark's bot implemented them then I'd definitely be ok with this feature.

[mpeters]

I'm find with merging this PR as-is and if we want to add to the auto-merge stuff with the new features that could be a separate PR if everyone is in agreement.

[mbestavros]

@mpeters @lukehinds Comment actions are definitely something I want to do, but it's a longer-term goal than this PR. Nothing preventing a patch from being filed whenever it is developed :)

[mpeters]

lgtm