Hi Luis.

As your TWS talk is nearing, I would like to present my views.

I think ${project}-integration job does basically the same thing

as ${project}-merge, only the triggers (and notifications) are different.
Build from source in ${project} git, run unit tests, upload artifacts.

*-merge is triggered by gerrit; *-integration should be triggered

by ${dependency}-merge and ${dependency}-integration jobs.

Maybe we should merge them to a single ${project}-publish job if possible.

> Is there going to be a centralized 'this is what integration looks like' job?

Yes, in integration project, but it would generally be too slow

and prone to failures.

That is why there will be ${project}-distribution jobs,

which pack only subtree of features relevant to that project.

They will be triggered by ${project}-publish,

and they will be triggering ${project}-scit jobs with end-to-end tests.

The same tests will be run also on the full integration build,

but once again that job would be slower.

> So I merge stuff to yangtools

From point of view of BGPCEP project, the following would happen.

1. yangtools-merge triggers controller-integration

(and nothing else yet if Jenkins is good at dependency handling).

2. controller-integration triggers tcpmd5-integration (and unrelated jobs)

3. tcpmd5-integration finally triggers bgpcep-integration

4. bgpcep-integration triggers bgpcep-distribution

5. bgpcep-distribution triggers bgpcep-csit jobs (several configurations).

6. bgpcep-csit-3nodes fails miserably, sends e-mails

to every upstream project. Probably including odlparent,

as Jenkins is not that good at back-tracing triggers.

…

96. Ultimately, integration-integration is triggered.
97. integration-integration triggers integration-distribution.

98. integration-distribution triggers integration-csit jobs.

99. After few hours all suites are finished (no idea who will be notified).

Question to Luis:
Is Jenkins that good at dependency handling,

or would bgpcep-integration be triggered three times

(yangtools-merge, controller-integration and tcpmd5-integration)?
If no, that motivates the strategy of triggering from *-merge jobs only,

and that would create the artifact race issue Robert was talking about.

But we will have race issues anyway, as yangtools-merge

will not wait patiently for integration-distribution to finish

before merging the next yangtools change.

Vratko.