[infra][upstream-institute] Bot to vote on changes in the sandbox

Sean Mooney smooney at redhat.com
Fri Feb 1 12:54:32 UTC 2019


On Fri, 2019-02-01 at 12:34 +0000, Jeremy Stanley wrote:
> On 2019-02-01 11:25:47 +0000 (+0000), Sean Mooney wrote:
> > 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 think that's basically what he was suggesting: a Zuul job which
> votes on (some) changes to the openstack/sandbox repository.
> 
> Some challenges there... first, you'd probably want credentials set
> as Zuul secrets, but in-repository secrets can only be used by jobs
> in safe "post-review" pipelines (gate, promote, post, release...) to
> prevent leakage through speculative execution of changes to those
> job definitions. The workaround would be to place the secrets and
> any playbooks which use them into a trusted config repository such
> as openstack-infra/project-config so they can be safely used in
> "pre-review" pipelines like check.
> 
> > 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
> 
> [...]
> 
> It would be a little weird to have those code review votes showing
> up for the Zuul account and might further confuse students. Also,
> what you describe would require a custom pipeline definition as
> those behaviors apply to pipelines, not to jobs.
yes i was suggsting a custom pipeline.
> 
> I think Tony's suggestion of doing this as a job with custom
> credentials to log into Gerrit and leave code review votes is
> probably the most workable and least confusing solution, but I also
> think a bulk of that job definition will end up having to live
> outside the sandbox repo for logistical reasons described above.
no disagreement that that might be a better path.
when i hear both i think some long lived thing like an irc bot that would
presumably have to listen to the event queue. so i was just wondering if we could
avoid having to wite an acutal "bot" application and just have zuul jobs
do it instead.




More information about the openstack-discuss mailing list