The process suggested by Denis is
successfully used by various Eclipse projects (using the Gerrit
trigger plugin, I think something similar exists for GitHub PR).
It indeed reduce the effort & risk of merging something.
On 09/24/2013 09:47 PM, Denis Golovin wrote:
1. More jenkins builds
We already have many jobs on Jenkins and the reactivity is not
always very good. Adding 30 to 40 more jobs will not make it better.
Despite of that, there is nothing preventing us from doing this.
Please open a Jira.
2. Have no Idea how to deal with PR's related to each other for
different components
It's concretely impossible to make sure a PR 123 of server builds
against what was suggested in PR 57 of base, for the following
reason:
* PR123 has no knowledge that it depends on another PR from another
component. So there is no way to automatically choose a specific
build output for another component.
* Job triggering is not deterministic since it depends on
availability of slaves, number of pull requests in the pipe, job
duration... So we can't rely on assumptions such as "PR were pushed
at the same time, so they'll build fine".
So in that case of linked PR, the output of automated build for PR
suggested above would be: green for PR57, red for PR123. The process
would be to merge PR57 first, build it with the regular job, and
then re-run build for PR123.
It's not a technical issue we're facing here, but a human one:
people (don't know how | don't take time) to make good reviews of a
PR. A good review requires at least one successful local build ("mvn
clean verify").
On that point GitHub misses something Gerrit has: the review has
configurable fields (Code-review, Verified for instance) which make
clear what is expected to be verified before merging a patch. It is
expected that someone (Hudson or Human) runs the build & tests
locally and vote +1 in verified, and that someone looks at the code
and vote +1 in Code-Review. Just having those flags shown encourage
people to make better review.