This group is locked. No changes can be made to the group while it is locked.
Date
1 - 6 of 6
[controller-dev] [releng] Distribution creation job
|
Edward Warnicke <hagbard@...>
Ah... good point :) I look forward to your presentation on Monday :) Ed
On Wed, Feb 25, 2015 at 12:49 PM, Luis Gomez <ecelgp@...> wrote:
|
|
|
|
Luis Gomez <ecelgp@...>
That is not going to work either because a given project cannot be sure which projects are in the downstream, instead the projects in downstream will launch their system test when they see a new distribution in the upstream (similar to the current <project>-integration-* are doing). BR/Luis
|
|
|
|
Edward Warnicke <hagbard@...>
Luis, Could you talk me through for example what this yaml file does: I can't see a section for either trigger or build for it... what causes it to trigger and what does it do? Ed
On Wed, Feb 25, 2015 at 12:37 PM, Edward Warnicke <hagbard@...> wrote:
|
|
|
|
Edward Warnicke <hagbard@...>
Ah... and Jenkins doesn't pass to you what jobs triggered it? Ed
On Wed, Feb 25, 2015 at 11:58 AM, Luis Gomez <ecelgp@...> wrote:
|
|
|
|
Luis Gomez <ecelgp@...>
That is not going to work Ed, the plan is to trigger different test plans depending on who triggers the distribution build. For that we need a distribution build per project. We discussed this in depth in our weekly calls + in the integration gathering few weeks ago. I will explain all that in the next TWS call but I just wanted to advance some of the jjb migration works this week. In any case someone has specific questions regarding current strategy with jjb can irc me. BR/Luis
|
|
|
|
Edward Warnicke <hagbard@...>
Luis, I thought that this was being handled by having in the integration cfg the jobs it depended on so it could run integration jobs like every other project does (see example of controller). I would think that would be the correct way, rather than putting new jobs in other projects... one place vs 43 places... Ed
On Tue, Feb 24, 2015 at 7:20 PM, Luis Gomez <ecelgp@...> wrote:
|
|
|