Hi All, During the Berlin forum the idea of running some kinda of bot on the sandbox [1] repo cam up as another way to onboard/encourage contributors.
The general idea is that the bot would: 1. Leave a -1 review on 'qualifying'[2] changes along with a request for some small change 2. Upon seeing a new patchset to the change vote +2 (and possibly +W?) on the change
Showing new contributors approximately what code review looks like[2], and also reduce the human requirements. The OpenStack Upstream Institute would make use of the bot and we'd also use it as an interactive tutorial from the contributors portal.
I think this can be done as a 'normal' CI job with the following considerations:
* Because we want this service to be reasonably robust we don't want to code or the job definitions to live in repo so I guess they'd need to live in project-config[4]. The bot itself doesn't need to be stateful as gerrit comments / meta-data would act as the store/state sync. * We'd need a gerrit account we can use to lodge these votes, as using 'proposal-bot' or tonyb would be a bad idea. do you need an actual bot why not just have a job defiend in the sandbox repo itself that runs say
On Fri, 2019-02-01 at 15:33 +1100, Tony Breeds wrote: pep8 or some simple test like check the commit message for Close-Bug: or somting like that. i noticed that if you are modifying zuul jobs and have a syntax error we actully comment on the patch to say where it is. like this https://review.openstack.org/#/c/632484/2/.zuul.yaml@31 so you could just develop a custom job that ran in the a seperate pipline and set the sucess action to Code-Review: +2 an failure to Code-Review: -1 the authour could then add the second +2 and +w to complete the normal workflow. as far as i know the sandbox repo allowas all users to +2 +w correct?
My initial plan would be to develop the bot locally and then migrate it into the opendev infra once we've proven its utility.
So thoughts on the design or considerations or should I just code something up and see what it looks like?
Yours Tony.
[1] http://git.openstack.org/cgit/openstack-dev/sandbox [2] The details of what counts as qualifying can be fleshed out later but there needs to be something so that contributors using the sandbox that don't want to be bothered by the bot wont be. [3] So it would a) be faster than typical and b) not all new changes are greeted with a -1 ;P [4] Another repo would be better as project-config is trusted we can't use Depends-On to test changes to the bot itself, but we need to consider the bots access to secrets