On 2019-12-13 18:01:03 +0100 (+0100), Thierry Carrez wrote: [...] > Ideally I would define my own narrow playbook to run the script, without > inheriting from the standard tox job. However the current script requires > some dependencies to be installed (openstack-governance, yaml...). > > Here are the options I see: > > 1- reimplementing most of the unittests/tox job logic in "hosts:localhost" > playbook(s) -- would mean lots of copypaste, does not rhyme so well with > "lightweight", and increases execution times significantly > > 2- rewrite the Python script so that it can run on stdlib -- not sure I want > to write a YAML parser from scratch though > > 3- Abandon the idea of running on the executor -- the trick is that for such > a short job the overhead of requesting a test node is a bit heavy, and we > want to run the job on every vote change on release requests > > Other ideas?
Stepping back and thinking about the overall goal (at least what I recall originally discussing), you basically want to look at what the change proposes to update in the releases repo, join that with project information in openstack-governance to get the list of liaisons, then contact Gerrit and add those liaisons as requested reviewers on the change or leave a review comment listing them (or maybe both), right? Assuming that's the case, the repos and Git and pyyaml are available to the workspace on the executor easily enough. Gerrit has a REST API and we have requests already importable too if Ansible's built-in HTTP module isn't sufficiently flexible... is that enough to get it done? That's basically what I was thinking about when I originally suggested a job "lightweight enough to run on the executor." I assumed it would work similar to some other jobs we already have which use an Ansible playbook to call a remote REST API with some supplied credentials based on some information in a change. Speculatively testing changes to the job will be tough of course because of the need to avoid leaking the Gerrit secret, but that's going to be the case with any playbook which needs to authenticate to a remote service. -- Jeremy Stanley
signature.asc
Description: PGP signature
_______________________________________________ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra