Last modified: 2013-06-20 19:53:35 UTC
Given that: * We're aiming to reserve 'verified' for automated CI, * We're aiming for all merges to be done by Jenkins, ..I think we should have Jenkins merge changes for +2'd patches even in repositories which do not configure any integration jobs. In such cases Jenkins would simply do a blind merge. One possible objection to this approach is that it seems wrong to have Jenkins certify a change without actually checking it in any way. I think this could be mitigated somewhat by adding a line to the Gerrit review message indicating this. (It could even have a link to some CI portal on mediawiki.org). If we want to drive home the thought that 'verified' should not be touched by human developers, the current approach is counterproductive. If you're used to Jenkins merging your changes (as I am), then you'll find you tend to +2 a change and then forget to verify / submit it. If you're used to working on repositories that don't have CI, then you are probably more likely to forget that 'verified' is for Jenkins, and try to submit / merge changes yourself. Either way, it's confusing. Another viable solution would be to configure Gerrit not to have a 'verified' step for repositories with no CI jobs. This might actually be a better solution, since it frees Jenkins from having to do the mindless step of verifying untested changes.
If there is no configuration in Zuul, no event will triggered for the repository. Similarly, if there is no job in Jenkins, it cant do anything :) What we could do is that upon a git repository creation we enforce having Zuul and Jenkins to be configured. All our repositories should really have a Jenkins job, even if it is just a linting one.
Sorry this is not possible. Zuul must have the repository configured.
