Open Stack

On Fri, 2019-02-01 at 15:33 +1100, Tony Breeds wrote:
> 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
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