On Wed, Sep 25, 2013 at 08:30:44AM +0200, Mickael Istria wrote:
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.
I really would like to see us use something like
https://github.com/maxandersen/buildchow
or maybe even the literatebuild approach
http://jenkins-ci.org/content/literate-builds-wtf
which
would allow for defining builds more 'declaratively' and easier to handle branches
and allow
one to reproduce our jenkins build setup locally and not be 117% tied to our
jenkins instances.
The number of jobs currently handedited or search/replaced and then sometimes edited on
the server
is making it very hard to share/move around to do things ike this "test run a
PR".
>2. Have no Idea how to deal with PR's related to each other
for
>different components
Basically these just won't be able to do with this approach imo.
But how many jobs do you actually have that needs this ?
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".
Even you could be deterministic - the jobs using a PR should not be publsihing
their result anywhere for downstream usage since it has been merged in yet.
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.
yes.