Envoy: GitHub bots tracking

[mattklein123]

This is a tracking issue for adding functionality to our development workflow with some GH bots. We can start by just figuring out which functionality we want and add it here. Then we can figure out resourcing and hosting later.

• [ ] Allowing org members to assign issues.
• [ ] Ping stale PRs.
• [ ] Auto fix DCO (bot would go through and rewrite all commits with a message that has the correct email sign-off).
• [ ] Auto update envoy-filter-example with latest envoy SHA, only opening an issue if the update does not cleanly pass tests (perhaps this could be done as a CircleCI job that only runs on master commits also).

@envoyproxy/maintainers please add other ideas.

Community members: If you want to help out but don't want to work on C++ this is a good option.

[alyssawilk]

stale code bot?

I think of "pinging stale PRs" being sending a reminder if there has been no recent action but there's also "warning of PRs with stale code" - almost all our build breakages have been someone with a 2+ week old master and no merge conflicts. I think if your're too far behind HEAD it should result in a bot warning to reviewer or a CI failure.

[alyssawilk]

Also is DCO-bot even doable? Arguably if the developer didn't sign off on a PR I don't think we can/should do it for them. Or is this if we merge something without leaving the DCO in the log?

[mattklein123]

Also is DCO-bot even doable? Arguably if the developer didn't sign off on a PR I don't think we can/should do it for them. Or is this if we merge something without leaving the DCO in the log?

Yes I think we can ask the PR author to type something like /fix_dco, only allow the PR owner to do it. Then the bot can do the actual work. I think it would be pretty awesome and save a lot of annoying back and forth for new contributors.

[alyssawilk]

Also maybe a bot which pings the author when tests are broken? May be too noisy but I see 8 open PRs with broken tests right now and I think often reviewers wait until tests are passing and authors don't check back and notice their tests failing.

[jmarantz]

Can we add a /kick_tests endpoint to CI?

I think @mattklein123 was referencing this issue from a slack comment.

[mattklein123]

@caniszczyk asks that we look at https://probot.github.io/apps/ first to make sure we can't use existing bots.

[cmluciano]

I think the assign option could be added if we leverage https://github.com/probot/commands . Can we create a new probot repository in Envoy so that we can store this config?

We'll have to host it somewhere, but there are easy steps for Glitch or Heroku here

[mattklein123]

@cmluciano sorry what needs to be done exactly?

[cmluciano]

I don't think that the probot/robot can be hosted through the GH Apps unless you leverage a 3rd party app. In order to retain the robot slash commands, I believe we need to create a repo with our specific config and then deploy it to a hosting provider.

• Fork https://github.com/probot/commands
• Commit our slash commands to our fork (assigning issues, labelling)
• Deploy to a cloud provider

I can try to host this in IBM Cloud if that helps

[mattklein123]

@cmluciano OK I will fork it today and give you write access. Will ping you when complete.

[mattklein123]

@cmluciano I forked here https://github.com/envoyproxy/commands and gave you write access.

[cmluciano]

@mattklein123 Apologies. I was confused on the granularity of these probot repositories. After reviewing the probot docs further and reaching out on their slack, the real solution is to create a new probot app. Then we just import modules such as probot/commands as node modules.

I was pointed at the probot skeleton repo here . Could you please delete the commands repo and create a blank repository called envoybot or envoy-probot ?

[mattklein123]

@cmluciano done: https://github.com/envoyproxy/envoybot

You should have write access.

[cmluciano]

Pushed assignee bot PR with some remaining todos

[mattklein123]

@cmluciano it appears that stale bot applies the "won't fix" label to issues, which seems broken (https://github.com/envoyproxy/envoy/issues/3435). Can you take a look?

[cmluciano]

Will do @mattklein123

[cmluciano]

@envoyproxy/maintainers I pushed a WIP for assignee bot but this is written in nodejs (could be typescript).

Based on the 6-19 community meeting we wanted to explore Github bots written in python and the closest thing I found was telegram. This could hypothetically be used for GH bot functionality, but it doesn't appear to be a core feature.

Based on the above can we select from the following options:

1. Continue leveraging probot framework written in nodejs
2. Experiment with using telegram or just creating a framework from scratch based on GH python libraries
3. Write custom functionality in python script format and call them from the probot framework

[mattklein123]

@cmluciano I would just do whatever is the least amount of work. Python is nice to have, not a requirement.

[cmluciano]

coming back to this finally,

I was retesting the nodejs bot for assignees, but I still have a strange backoff loop when a Github user does not exist.

I was wondering what the appetite for using something like prow would be. We can configure just the slash command plugins and it has fine grained permissions.

If prow doesn't seem like a good option, I'll keep debugging the current issues in our probot framework.

[cmluciano]

Also, can someone assign this issue to me?

[htuch]

@cmluciano we were considering Prow as a self-hosted CI a while back, but decided to keep things simple and continue with a managed service, hence CircleCI. If Prow would be useful as a bot or non-canonical orchestration (i.e. integrating as a slave to CircleCI), then this sounds like something interesting.

My main concern with Prow is complexity; at the time, it was a big chunk of Go code with k8s focus, so being able to hack on it as a regular Envoy developer might prove challenging. Things my have changed, and if someone like you can own this, then it makes sense to consider.

[cmluciano]

SGTM. I think Prow bot utilities are useful and would be prepared to own the maintenance. In the future i definitely think your idea of using it for supplemental builds would be great too.

I will hack on this now and demo against the envoybot repo.

[junr03]

I think if your're too far behind HEAD it should result in a bot warning to reviewer or a CI failure.

Adding a big +1 to this, it just burned me again with https://github.com/envoyproxy/envoy/pull/2957

[cmluciano]

FYI another community member had some ideas on this and should be demo'ing something to me that may not be as heavyweight as prow. I'll continue to poke at assigneebot for now since a coworker can help review my JS.

[itayd]

Heads up, first PR inbound: https://github.com/envoyproxy/envoy/pull/4852. This brings the assign module in.

[cmluciano]

@itayd This is great! Any ETA on dev docs for new plugins on https://github.com/softkitteh/repokitteh-modules/ ?

I'd like to try one out for adding labels to issues?

[itayd]

@cmluciano not yet - i'm busy writing the new modules per the sow. when these are operational, next step is docs (after some refactoring i have in mind that might affect docs).

that said - you can have a go at it now, play with it in envoybot - you can use the existing modules for examples and you can always ask me questions.

[itayd]

PR out for documenting currently supported behavior: https://github.com/envoyproxy/envoy/pull/4906

Next up activity and rekick-circle bot.

[itayd]

might as well

/assign @itayd

[itayd]

Waiting command now in: https://github.com/envoyproxy/envoy/pull/4956.

[itayd]

Retest command: https://github.com/envoyproxy/envoy/pull/5047

[mattklein123]

I'm going to call this tracking issue done. Let's open specific bot issues at this point so they are easier to track.