Re: [opendaylight-dev] [opendaylight.org #8922] [linuxfoundation.org #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! Thanks, Robert 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? BR/LuisOn 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, because 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 rebuilt.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 ;) -Andy- -- Andrew J Grimberg Systems Administrator The Linux Foundation <Mail Attachment> |
|
|