On Mon, Jul 9, 2018, at 3:31 AM, Rikimaru Honjo wrote: > Hello Clark, > > Thank you for your information. > But, sorry, I have some additional questions. > > On 2018/07/07 1:11, Clark Boylan wrote: > > On Fri, Jul 6, 2018, at 1:49 AM, Rikimaru Honjo wrote: > >> Hello, > >> > >> I'd like to add a third party CI of networking-spp project.[1] > >> But, I have some question about it. > >> I'd appreciate it if you give information. > >> > >> My wishes are the following: > >> > >> * I'd like to run my test on my environment. > >> Because my test requires special environment. > >> * I'm planning that check new patch-sets and run my test by ZuulV3. > >> > >> So I built ZuulV3 and nodepool on my environment, and pushed .zuul.yaml > >> to gerrit.[2] > >> > >> But, the following error was returned. > >> Should I add settings of my third party CI to project-config in this case? > >> If it is "Yes", is there documents about the way? > >> > >> I confirmed > >> <https://docs.openstack.org/infra/system-config/third_party.html>, > >> but there was no information for ZuulV3. > >> > >>> Zuul encountered a syntax error while parsing its configuration in the > >>> repo openstack/networking-spp on branch master. The error was: > >>> > >>> Pipelines may not be defined in untrusted repos, they may only be > >>> defined in config repos. > >> > >> > >> [1] > >> https://github.com/openstack/networking-spp > >> > >> [2] > >> https://review.openstack.org/#/c/580561/1 > > > > The Zuul config in the projects that OpenStack Infra hosts apply to the > > OpenStack Zuul instance. Certain aspects of this config must be defined in > > a trusted repo to protect this instance from unintended (or even malicious) > > updates in the repos we host. The error you ran into is a case of this. > > > > In particular pipelines define when and how zuul should run jobs so we > > don't want anyone to be able to update that without review in central > > trusted config. > > > > As for how to do this for third party CI, your Zuul would need to have its > > own trusted config (for the same reasons as above, but protecting your Zuul > > instance not ours). That config will have pipelines defined. If the project > > is comfortable with it you can define the jobs and playbooks and roles for > > third party CI in the upstream project. Then you would select to run those > > jobs in your Zuul's local config and report the results back to Gerrit from > > there. > > In this case, should I add a part of my settings to openstack-infra/ > project-config?
No you will need to host your own trusted repo. > > > Or if the upstream project wants to keep that data out of tree you can > > configure all of it in your Zuul config locally. One drawback to hosting > > the job config upstream would be that changes to the job config can be made > > without gating them and ensuring that they work (because third party CI can > > only vote +/-1). This problem is likely less of an issue if reviewers > > respect the third party CI results. > > In this case, should I put config-projects on local environment and > report the test results to review.openstack.org? > But, in my understanding, "config-projects" in tenant.yaml should be put > under the source of the connection which is the target of reporting. > If my understanding is correct, I think that config-projects can not be > prepared locally. It can be prepared locally using the git driver, https://zuul-ci.org/docs/zuul/admin/drivers/git.html . This is probably the simplest way to start then you can consider hosting your config on a Gerrit or Github at a later time. Chances are if this is a simple setup that the git driver may work long term. > > > I think to start I would mostly keep what you've done, but move the > > pipeline definitions and project config that says what jobs to run into > > your Zuul's config. > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra _______________________________________________ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
