[Github Action] Add backport workflow

[sorenlouv]

This adds the backport Github action.

It will automatically create backports for PRs containing the auto-backport label. The PRs will be merged automatically when they pass CI (this can be turned off if deemed too scary).

@brianseeders looks good to you?

[elasticmachine]

Pinging @elastic/agent (Team:Agent)

[ruflin]

@ph Can you make sure we have all the necessary label in place and the team is aware of this.

@sqren THANK YOU!

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Build Cause: Pull request #24576 updated

• Start Time: 2021-03-17T07:55:16.547+0000

• Duration: 11 min 6 sec

• Commit: b232314

Trends 🧪

❕ Flaky test report

No test was executed to be analysed.

[sorenlouv]

This secret can be added via Github repos settings.

[kuisathaverat]

this is one of the reasons we do not want to use actions, the management of secrets.

[sorenlouv]

Is there a Github user for beats similar to kibanamachine?

[brianseeders]

Yeah, they should use something other than kibanamachine, probably elasticmachine or their jenkins-beats-ci bot?

[v1v]

Hey @sqren , thanks for raising this PR! 🙏

I like this approach, in fact, it was in our TODO list among evaluating other tools such as mergify.

What Ivan mentioned about the credentials is something we would like to spend a bit more of time to think about it and come up with a final decision with the Beats team.

Would you mind if I ask you to hold on this PR for the time being until we get an agreement?

Thanks again for pushing this 🙏

[ph]

@sqren I am trying to understand the auto-merge workflow, does that mean that you tag a PR with "auto-backport" and you add a label for the version / branch to target? Is this used by Kibana already? Is this the official doc https://github.com/sqren/backport-github-action ?

@v1v and @kuisathaverat I understand the complexity of managing secrets, but this seems something that could simplify dev workflow and the "managing' of secret could come after, or actually it's a problem we would need to solve anyway? If other teams are using a similar workflow, either they are fine with the token or they actually have something to manage it.

Looking at @ruflin comment and myself I would be OK to turn it on, maybe with auto merge off initially until we see how it behaves and turn it on after.

[sorenlouv]

@sqren I am trying to understand the auto-merge workflow, does that mean that you tag a PR with "auto-backport" and you add a label for the version / branch to target?

Yes, the user adds auto-backport to PRs they want to enable auto backporting for. Then, when the PR is merged, the action will create backports according to the existing version labels eg v7.11.0, v7.12.0, v7.13.0

Is this used by Kibana already?

Yes! You can see all the PRs with the auto-backport label. You can also see this example of the status comment added by the action when the backports have been created.

Is this the official doc sqren/backport-github-action ?

No - it was the initial POC I did. Based on that the Kibana team then built this: https://github.com/elastic/kibana-github-actions/tree/main/backport

[kuisathaverat]

@v1v and @kuisathaverat I understand the complexity of managing secrets, but this seems something that could simplify dev workflow and the "managing' of secret could come after, or actually, it's a problem we would need to solve anyway? If other teams are using a similar workflow, either they are fine with the token or they actually have something to manage it.

The secret is managed at the repository level, this is fine is you only have one repository on observability we have more than 90 repositories, this means that every time we rotate that token we have to update 90 repositories, because of that @v1v is testing alternatives, we have enabled mergify on out repository, and so so good, for public repositories fit the needs.

[v1v]

I just raised #24608 in order to add more context about the mergify approach.

[brianseeders]

mergify looks cool! I do like that on for kibana, though, we have the same backport tool/process for both automated and manual backports.

If you do want to use an action similar to ours, you have a couple of options for the secrets:

• You could just use the default action user / token that executes the action, you just won't have control over the name.
• You could use the API to set the secrets on all of the repos in bulk
• You could use an organization secret, but you'll have to get help from Infra or another team to manage it (since you likely don't have access).

Not trying to push you toward actions, just making sure you're aware of options.