[Starlingx-discuss] upstream -infra queue setup might need tweaking to handle cross-project dependencies

[Anaya casas, Hazzim I]

I believe the concern is related to this config in Zuul and we need to take advantage of this feature.

Cross Project Testing
When your projects are closely coupled together, you want to make sure changes entering the gate are going to be tested with the version of other projects currently enqueued in the gate (since they will eventually be merged and might introduce breaking features).

Such relationships can be defined in Zuul configuration by placing projects in a shared queue within a dependent pipeline. Whenever changes for any project enter a pipeline with such a shared queue, they are tested together, such that the commits for the changes ahead in the queue are automatically present in the jobs for the changes behind them.

https://zuul-ci.org/docs/zuul/user/gating.html




On Jun 27, 2018, at 14:31, Scott Little <scott.little at windriver.com<mailto:scott.little at windriver.com>> wrote:

Agreed, I don't think we can function without it.

Is there a way to get a notification sent to reviewers of the blocking review, the one that is depended on but is not recieved it's CR+2, W+1, that this review needs urgent attention?

If the depended on review is failed or abandoned, can the blocked review by automatically dequeued?  Demoted to W0?  Ideally with a notification?

Scott


On 18-06-27 03:12 PM, Dean Troyer wrote:
On Wed, Jun 27, 2018 at 1:43 PM, Chris Friesen
<chris.friesen at windriver.com<mailto:chris.friesen at windriver.com>> wrote:
The automated way to handle this is to have all the potentially
interdependent projects share a queue by specifying a common queue name.
The example given was the "integrated" queue for nova and friends, as
specified at
https://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul.d/projects.yaml#n108
Dang, I forgot this bit when setting up the jobs, so something like
this? https://review.openstack.org/578532

This does potentially introduce merge delays since it will serialize merges
across all the projects that share a queue, but for tightly-coupled projects
it might make sense.
It think totally makes sense here...

dt



_______________________________________________
Starlingx-discuss mailing list
Starlingx-discuss at lists.starlingx.io<mailto:Starlingx-discuss at lists.starlingx.io>
http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20180628/7442e230/attachment.html>