On 07/08/2016 11:19 AM, Lori Jakab wrote: > Hi, > > On Fri, Jun 10, 2016 at 9:06 AM, Lori Jakab <[email protected] > <mailto:[email protected]>> wrote: > > On Wed, Jun 8, 2016 at 6:44 PM, Jamo Luhrsen <[email protected] > <mailto:[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.
This is awesome progress, Lori. Thanks for sharing the status and script. I think HPE is also considering this. JamO > -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]> > <mailto:[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 > <mailto:[email protected]> > <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]> > <mailto:[email protected] > <mailto:[email protected]>> > >> https://lists.opendaylight.org/mailman/listinfo/infrastructure > > > > > > > > _______________________________________________ > > Discuss mailing list > > [email protected] > <mailto:[email protected]> > > https://lists.opendaylight.org/mailman/listinfo/discuss > > > _______________________________________________ > Discuss mailing list > [email protected] <mailto:[email protected]> > https://lists.opendaylight.org/mailman/listinfo/discuss > > > _______________________________________________ Discuss mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/discuss
