Re: [opendaylight-dev] [ #8922] [ #8922] System Test after code push in a top upstream project

Robert Varga

Actually, I think this would be better solved by staging the artifacts for the downstream build(s), which quickly brings you to managing a continuous delivery pipeline -- this sort of validation is a typical example of a gate.

Mathieu, you mentioned you had a prototype, correct?

Also, preventing such changes from verifying while we integrate the system on unreleased snapshots effectively means the APIs are frozen at the time we introduce SNAPSHOT version bump, e.g. upstream projects may not change APIs incompatibly in their development cycle!


On 01/21/2015 07:39 AM, Luis Gomez via RT wrote:

Hi Andy and Thanh,

I just realized there is something important we need to address with high priority: to be able to trigger a system test after code push (verify job) in a top upstream projects like odlparent, yangtools or controller.

The challenges:

- We do not store artifacts in Nexus after code push
- We cannot build a distribution within these projects, that will break the dependency chain

One idea I just got: would it be possible to add some automation after the verify build (in same verify job) that:

1) Downloads the latest integration karaf distribution (jenkins or nexus)
2) Unzips the distribution and copies the verify job generated artifacts in ~/.m2 folder to the distribution ~/system folder
3) zips the distribution and stores it in jenkins
4) Triggers a system test job passing the jenkins link for the just created distribution

Is this feasible? any other idea to make this happen?


On Jan 19, 2015, at 2:44 PM, Andrew Grimberg via RT <helpdesk@...> wrote:

On Mon, 2015-01-19 at 22:32 +0000, Ed Warnicke via RT wrote:

I think you are correct that pretty much all projects should name odlparent
as a dependency.

The other reason that this came up was because of a very very unusual java
erasure issue
that caused us to need to rebuild downstream projects.  It was a weird one,
the source code of the upstream method had not changed, and but because of
how the
erasures were resolved, the binaries downstream did not recognize it until
In any case, the request to be have a downstream project trigger an
upstream project to rebuild would essentially cause an infinite chained
reaction loop of a downstream project rebuilding because the upstream
project rebuilt which would then trigger the upstream project to
rebuild... loop and repeat.

Which is my way of saying, the initial request isn't feasible ;)


Andrew J Grimberg
Systems Administrator
The Linux Foundation

<Mail Attachment>

dev mailing list

Join to automatically receive all group messages.