On 2019-03-14 05:23 PM, Jeremy Stanley wrote:
On 2019-03-14 16:57:09 -0400 (-0400), Andy Ning wrote:
[...]

[AN]: As developer I don't install anything, I submit my source code changes
to gerrit as review, and Zuul is triggered to run to verify if my change
break tox. Where tox runs the tests and what its environment like is
transparent to (as least for me until now :)). So I'm not sure how I could
do what you suggest.

By "you" in this case I meant developers on StarlingX. Your CI jobs
should absolutely not be a black box to you, especially since the
job in question is defined in your repository:

    http://git.starlingx.io/cgit/stx-config/tree/.zuul.yaml#n66

Just a matter of adding "nodeset: ubuntu-xenial" to that job
definition. The change which adds it should be self-testing so
you'll be able to see in the CI results whether it worked or not.


Good to know that we can somehow control the job by the .zuul.yaml file. I would think adding a nodeset to the job should be a temporary workaround. Overall I'm not sure we want to specify where a particular job is running (will that be a load balancing issue for Zuul for example?).  Plus most of us want to focus on the production code, so hiding Zuul job details may not be a bad idea for developers (maybe that's the reason why .zuul.yaml is  hidden file?)

In terms of self-testing, I usually run tox locally on our build machine and that works fairly well. Is there a way we can trigger Zuul jobs on our change before we sumit the review? The idea is developers run tox in the same environment as Zuul runs it.

Thanks,
Andy   


_______________________________________________
Starlingx-discuss mailing list
Starlingx-discuss@lists.starlingx.io
http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss


-- 
Andy Ning
Cube: 3071
Tel: 613-9631408 (int: 4408)
Skype: andy.ning.wr