From Fedora Project Wiki
Martinpitt (talk | contribs) (question why examples install the test) |
m (Kevin moved page Changes/Openldap 25/InvokingTestsAnsible to Talk:Changes//InvokingTestsAnsible: undoing previous move) |
||
(8 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
* Martin Pitt: Why is there an "install the test" step? That seems thoroughly unnecessary with keeping the tests in dist-git, and in fact should be avoided as `/usr/` really should remain package manager territory. | * Martin Pitt: Why is there an "install the test" step? That seems thoroughly unnecessary with keeping the tests in dist-git, and in fact should be avoided as `/usr/` really should remain package manager territory. | ||
* Stef Walter: Is the run-tests.yml in the top level of the dist-git repo? If not, the standard should document the subdirectory that it lives in. The examples are confusing here although the standard says the tests are stored in dist-git the examples are not dist-git style repositories. | |||
* Stef Walter: By default, Ansible sets the current directory to the one that stores the playbook. The output artifacts always end up in the same directory as `run-tests.yml`. Should we make an environment variable or somehow specify a fixed directory where they should go? | |||
* Handling test subjects in Ansible is hard. Should we have different entry point scripts for different kinds of test subjects? For example `test-rpm.yml` and `test-qcow2.yml` and `test-module.yml` and `test-ostree.yml`. These playbooks could share Ansible roles and modules, or invoke one another (eg: against a VM the first ansible playbook provisioned). | |||
* re "thinking of linch-pin": These things come/go, better to reference the cloud-control bits indirectly. This can be done simply in ansible by a role that: | |||
* The inventory-name of a host is defined in a variable | |||
* Run a list of asserts, defined in a variable (verifies expected state) | |||
* Run a command defined by a variable, output expected to be / parsed as YAML. | |||
* Use add_host against the output YAML | |||
* Profit | |||
Just make that role shared via the central-repo, and every package can use whatever provisioning system/setup/script it wants to. |
Latest revision as of 20:09, 25 October 2021
- Martin Pitt: Why is there an "install the test" step? That seems thoroughly unnecessary with keeping the tests in dist-git, and in fact should be avoided as
/usr/
really should remain package manager territory.
- Stef Walter: Is the run-tests.yml in the top level of the dist-git repo? If not, the standard should document the subdirectory that it lives in. The examples are confusing here although the standard says the tests are stored in dist-git the examples are not dist-git style repositories.
- Stef Walter: By default, Ansible sets the current directory to the one that stores the playbook. The output artifacts always end up in the same directory as
run-tests.yml
. Should we make an environment variable or somehow specify a fixed directory where they should go?
- Handling test subjects in Ansible is hard. Should we have different entry point scripts for different kinds of test subjects? For example
test-rpm.yml
andtest-qcow2.yml
andtest-module.yml
andtest-ostree.yml
. These playbooks could share Ansible roles and modules, or invoke one another (eg: against a VM the first ansible playbook provisioned).
- re "thinking of linch-pin": These things come/go, better to reference the cloud-control bits indirectly. This can be done simply in ansible by a role that:
* The inventory-name of a host is defined in a variable * Run a list of asserts, defined in a variable (verifies expected state) * Run a command defined by a variable, output expected to be / parsed as YAML. * Use add_host against the output YAML * Profit
Just make that role shared via the central-repo, and every package can use whatever provisioning system/setup/script it wants to.