Greetings, A few weeks ago, I sent an email to the zuul-discuss[1] ML talking about the idea of splitting a base job in project-config into trusted / untrusted parts. Since then we've actually implemented the idea in rdoproject.org zuul and seems to be working very well.
Basically, I'd like to do the same here with our base job but first wanted to give a heads up. Here is the basic idea: project-config (trusted) - job: name: base-minimal parent: null description: top-level job - job: name: base-minimal-test parent: null description: top-level job for testing base-minimal openstack-zuul-jobs (untrusted) - job: name: base parent: base-minimal This then allows us to start moving tasks / roles like configure-mirrors from trusted into untrusted, since it doesn't really need trusted context on the executor. In rdoproject, our base-minimal job is much smaller then openstack-infra today, but really has just become used for handling secrets (post-run playbooks) and zuul_stream (pre). Everything else has been moved into untrusted. Here, we likely need to have a little more discussion around what we move into untrusted from trusted, but once we've done the dance to place base into openstack-zuul-jobs and parent to base-minimal in project-config, we can start testing. We'd still need to do the base-minimal / base-minimal-test dance for trusted context, but it should be much smaller the things we need to test. As a working example, the recent changes to pypi mirrors I believe would have been much easier to test in this setup. - Paul [1] http://lists.zuul-ci.org/pipermail/zuul-discuss/2018-July/000508.html _______________________________________________ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra