Open Stack

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.

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.

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.

Hope this helps,
Clark