On Tue, Feb 21, 2017 at 10:23 PM, Martin Sivak <[email protected]> wrote: >> Finally realizing the potential for harm, we acted quickly to >> re-enable the whitelist mechanism. We made an effort to include >> current authors and maintainers, but we do not know everyone. People >> not included in the whitelist will see the following message when >> submitting patches: > > How can the maintainer trigger the CI for a 3rd party patch? We won't > merge anything that didn't pass the tests first so we need a way to > trigger them.
Triggering the patch manually does not work, even if a valid user trigger the build. My poor workaround was to upload the next version of a patch. In vdsm we can also run the tests on travis. After your setup travis on your fork in github, you can push the change to github to test it like this: git review -d patch-number git push github Using: $ git remote -v | grep github github [email protected]:nirs/vdsm.git (fetch) github [email protected]:nirs/vdsm.git (push) Interesting that Travis is not worried about everyone running CI, no whitelist is needed :-) > > -- > Martin Sivak > oVirt / SLA > > On Tue, Feb 21, 2017 at 6:53 PM, Barak Korren <[email protected]> wrote: >> TL;DR: If you are a patch author, please ask your project maintainer >> to have you added to the CI whitelist. >> >> The oVirt CI system tries to be a useful and powerful tool for patch >> authors and project maintainers. With the current CI-standards, power >> is placed in the hands of patch authors to make the system do almost >> anything. >> >> We try to be an "open" Open-Source project, so permission is given to >> anyone to open a Gerrit account and submit patches. >> >> The above opens the door to the CI system being maliciously exploited, >> so some countermeasure was needed. The builders of the CI system >> foresaw this and have put in place a white-list mechanism that makes >> the CI system only run jobs for patches that come from listed authors. >> >> In recent years the CI system had been re-engineered with the push >> towards the CI standards, and the whitelist mechanism was rendered >> non-active. >> >> Finally realizing the potential for harm, we acted quickly to >> re-enable the whitelist mechanism. We made an effort to include >> current authors and maintainers, but we do not know everyone. People >> not included in the whitelist will see the following message when >> submitting patches: >> >> To avoid overloading the infrastructure, a whitelist for >> running gerrit triggered jobs has been set in place, if >> you feel like you should be in it, please contact infra at >> ovirt dot org >> >> If you come across this message, please ask the project maintainer to >> send a message to the infra team asking for you to added to the CI >> whitelist. We'd rather not receive direct messages from individual >> contributors, because we do not know everyone and cannot verify >> sources. >> >> We (the infra team) know that the current mechanism can sound >> draconian and be inconvenient. But we had to put something in place >> quickly. Please join the discussion at [1] to improve it. >> >> [1]: https://ovirt-jira.atlassian.net/browse/OVIRT-1154 >> >> -- >> Barak Korren >> [email protected] >> RHCE, RHCi, RHV-DevOps Team >> https://ifireball.wordpress.com/ >> _______________________________________________ >> Devel mailing list >> [email protected] >> http://lists.ovirt.org/mailman/listinfo/devel > _______________________________________________ > Devel mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/devel _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
