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?
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.
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
_______________________________________________
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Rikimaru Honjo
E-mail:honjo.rikim...@po.ntt-tx.co.jp
_______________________________________________
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
