Hi, On Fri, Jun 10, 2016 at 9:06 AM, Lori Jakab <[email protected]> wrote:
> On Wed, Jun 8, 2016 at 6:44 PM, Jamo Luhrsen <[email protected]> wrote: > >> Let's bring this topic up in the Integration call tomorrow as well. >> >> Lori, Andy usually attends that call if you had the time to make it >> and wanted to have any discussion. >> > > Hi JamO, > > Sorry I missed that call. I will look into this when I get a chance with > the info from Andy, and follow up on this thread if I make progress or hit > issues. > This work has been (and is still) on the back-burner, but I just wanted to report a small progress. Based on the example script from the pygerrit repo [0] I have a script that is listening for gerrit stream events, filters for lispflowmapping new patch set events, and adds a (non-voting for now comment). Here's an example [1], look at the second comment :D it was added by the "external CI". >From here, we'll work on defining some basic tests, and adding voting. One step at a time. -Lori [0] https://github.com/sonyxperiadev/pygerrit/blob/master/example.py [1] https://git.opendaylight.org/gerrit/#/c/41572/ > Thanks for all the input. > > Regards, > -Lori > > >> >> JamO >> >> On 06/08/2016 08:37 AM, Luis Gomez wrote: >> > Just let everybody know, system test today is not triggered or does >> vote in gerrit. The current workflows for system test are: >> > >> > - New distribution in project X -> Run system test in all downstream >> projects. >> > - New release distribution -> Start distribution test -> Run all stable >> system test. >> > - Patch test -> Create distribution -> Start distribution test -> Run >> all stable system test. >> > >> > So in all above cases it is Jenkins (not gerrit) who triggers the >> system test. >> > >> > This means a Jenkins Master-Slave communication between ODL (Master) >> and the external Lab (Slave) would be sufficient and optimal to work with >> the >> > existing flows. >> > >> > Another simpler solution (and firewall friendly) would be to setup a >> Jenkins Master in the external Lab and trigger on Jenkins URL events like >> it is >> > described here [1]. This solution works vey good but does not report >> test results back to ODL. >> > >> > BR/Luis >> > >> > [1] >> https://wiki.opendaylight.org/view/CrossProject:Integration_Group:Jenkins_Integration >> > >> > >> >> On Jun 8, 2016, at 6:20 AM, Andrew Grimberg < >> [email protected] <mailto:[email protected]>> >> wrote: >> >> >> >> On 06/07/2016 04:26 PM, Lori Jakab wrote: >> >>> >> >>> As I've stated numerous times, yes we can do "third party" CI. All >> that >> >>> is needed is the following: >> >>> >> >>> a) create an ODL identity of the name ${THIRD_PARTY}-ci or >> something >> >>> equally obvious that it's a CI system >> >>> >> >>> b) send a request to the helpdesk requesting that the account be >> granted >> >>> stream rights and also what what project you want it to be able to >> vote >> >>> verify on. >> >>> >> >>> c) Use that account for in your third-party CI system to watch the >> >>> gerrit queue and trigger jobs as needed as well as to vote. >> >>> >> >>> >> >>> This is the part that I'm a bit unclear about... does this third-party >> >>> CI need to be a "well known" (==supported) CI system, or could it in >> >>> theory be a hacked together collection of scripts, respecting some >> kind >> >>> of communication protocol (which one)? How would we watch the gerrit >> >>> queue? Email notifications, or something else? >> >> >> >> To be honest, I don't care what the CI is as long as it's well behaved. >> >> I do, however, want the identity to be well identified as a CI system >> >> and we probably do need to have a wiki section to identify all Third >> >> Party CI systems and how to force them to re-run tests. Which is >> >> something that the CI system needs to support. >> >> >> >> As for watching the queue. Gerrit has a stream API [0] which we would >> >> grant access to. This API is attached to via the SSH socket. >> >> Alternatively, you can use the REST API [1] without needing any special >> >> rights. You will, however, need to actively poll if using the REST API, >> >> whereas the stream API is an active lingering listen only connection. >> >> >> >> If you're using Jenkins as the CI then to utilize it you would install >> >> the Gerrit Trigger plugin and define an Gerrit system in the plugin for >> >> use. This would be the same way we currently define job triggering in >> ODL. >> >> >> >> The voting component would be done via the SSH interface to Gerrit. If >> >> your curious on how this part operates do the following: >> >> >> >> ssh -p 29418 ${youruser}@git.opendaylight.org < >> http://git.opendaylight.org> gerrit review --help >> >> >> >> -Andy- >> >> >> >> [0] >> https://git.opendaylight.org/gerrit/Documentation/cmd-stream-events.html >> >> >> >> [1] https://git.opendaylight.org/gerrit/Documentation/rest-api.html >> >> >> >> -- >> >> Andrew J Grimberg >> >> Systems Administrator >> >> Release Engineering Team Lead >> >> The Linux Foundation >> >> >> >> _______________________________________________ >> >> infrastructure mailing list >> >> [email protected] <mailto: >> [email protected]> >> >> https://lists.opendaylight.org/mailman/listinfo/infrastructure >> > >> > >> > >> > _______________________________________________ >> > Discuss mailing list >> > [email protected] >> > https://lists.opendaylight.org/mailman/listinfo/discuss >> > >> _______________________________________________ >> Discuss mailing list >> [email protected] >> https://lists.opendaylight.org/mailman/listinfo/discuss >> > >
_______________________________________________ Discuss mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/discuss
