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