Bot functionality

[cmelone]

Problem/Opportunity Statement

Hubcast should provide a mechanism to receive commands via a bot-like interface.

What would success / a fix look like?

Implement the following commands that can be called within PRs with @hubcast command:

• help - list of all commands and simple documentation
• approve - if a PR is submitted by a user who doesn't have push permissions to the Gitlab destination, one of the repo maintainers can allow hubcast to run the pipeline on their behalf
• run - start a new pipeline, for any reason

TODOs/notes:

• Re-run pipelines leaves multiple concurrent pipelines for the same PR spack/spackbot#85
• document permissions needed to perform actions
• automatically cancel pipelines/jobs that are irrelevant due to new pushes?

items to address in future work:

• consolidate logic between GitHub and gitlab -- wrappers for commenting, reacting, etc
• should we allow run on commit comments to allow for execution outside the context of a PR? or is this not super intuitive for the user?
• Add a command to re-run only pipelines that had system failures spack/spackbot#101
• Spackbot should replay webhooks sent during a downtime spack/spackbot#89

[cmelone]

@alecbcs question about authorization:

scenario

• user 1 is not part of the account mapping and submits a PR to an LLNL repo
• user 2 is part of the LLNL account mapping, but doesn't have permissions to the repo besides read

should user 2 be allowed to "approve" a PR and have the pipeline execute under their LC account?

[alecbcs]

Yeah, as long as user 2 has an LC account they should be able to allow the CI to kick off under their account. I agree "approve" here makes it seem as though they should also have access to the repository, but plenty of folks will forget to add folks to a repository before they expect them to help out with PRs.

[cmelone]

I'm also assuming that an approval shouldn't have any memory, ie someone would need to approve the hubcast sync after every new push

[alecbcs]

Yep correct. We don't want someone to push malware right after getting some legitimate code approved.

[cmelone]

The way I'm writing the approve functionality is to basically call sync_pr on the commenter's behalf.

Say a non-LC contributor closes their PR. Correct me if I'm wrong, but someone would need to go approve the call to remove_pr in order to perform the cleanup.

Is it reasonable to assume that people will actually go approve PR deletions? or should the responsibility of branch cleanup be the repo owner's responsibility?

[alecbcs]

That's a good edge case. For the most part, I think folks with LC accounts will accept / merge PRs which will clean them up automatically. In the case a user without an LC account closes the PR I think it's acceptable to leave it for someone to manually clean up.

[cmelone]

is there any situation where a user not in the account map would need to interact with the bot?

if gitlab_user is None:
    log.info(f"Unauthorized GitHub User: {github_user}")
    return web.Response(status=200)

this check would block a random user from triggering a response to /hubcast help, but I couldn't think of why they'd need to do that or have hubcast perform any other action on their behalf.

[alecbcs]

I can't think of one at the moment. We might want to have a callback in that check one day to alert users of this, but for now I think it's fine to drop the request without a response.

[cmelone]

Regarding these two items:

• Re-run pipelines leaves multiple concurrent pipelines for the same PR spack/spackbot#85
• automatically cancel pipelines/jobs that are irrelevant due to new pushes?

I started to write up the implementation, which would essentially cancel all existing pipelines for a ref in GL if a user ran /hubcast run pipeline.

However, I realized that we would need to differentiate between the pipelines triggered by Hubcast and pipelines potentially scheduled by the project maintainers that they wouldn't want canceled.

We could leave this feature as an option, but without the ability to configure the behavior easily, it might be more trouble than it's worth.

Gitlab has this "auto cancel redundant pipelines" feature that I can never get to work, but it's probably best to leave this stuff to maintainers.