On November 28, 2017 7:37 pm, James E. Blair wrote:
Jens Harbott <[email protected]> writes:

2017-11-23 5:28 GMT+00:00 Tristan Cacqueray <[email protected]>:
...
TL;DR; Is it alright if we re-enable this CI and report those tests on
      zuul-jobs patchsets?

I like the general idea, but please wait for more feedback until doing so.

I am in favor of the idea in general, thanks!

Also, IMHO it would be better if you could change the "recheck-sf"
trigger to something that does not also rerun upstream checks. What
seems to work well for other projects is "run ci-name", where ci-name
is the name of the Gerrit account.

Actually, I'd prefer that we do the opposite.  I'd like the recheck
command for both to just be "recheck".  There's no harm in both systems
re-running tests for a change in this case, and it keeps things simpler
for developers.  The requirements in
https://docs.openstack.org/infra/system-config/third_party.html#requirements
state that all systems should honor "recheck".  I'd like to go beyond
that in zuul-jobs and say that third-party ci systems on that repo
should *only* honor "recheck".

How about supporting both comments, like that we can still recheck a
single CI system? When doing tests, there is no need to consume other
CI resources...

In the meeting today we agreed that we should start by reporting without
voting, gain some confidence, then enable +1/-1 voting.

-Jim

Thanks for the feedback. I've increased coverage by creating more jobs,
though I didn't enable the patchset-created event yet because zuul-jobs
isn't usable as-is on our systems, mostly because zuul isn't sudoer.

Here is a collection of fix to cover the bare minimal roles
(prepare-workspace, emit-ara) and to run the tox job on CentOS:
https://review.openstack.org/#/q/topic:fix-centos-7

CI is success on https://review.openstack.org/525510
And a negative test is working on https://review.openstack.org/522438

Regards,
-Tristan

Attachment: pgpw_UVmPQyr4.pgp
Description: PGP signature

_______________________________________________
OpenStack-Infra mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Reply via email to