From Fedora Project Wiki
No edit summary
 
(7 intermediate revisions by 3 users not shown)
Line 2: Line 2:


* 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: 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 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.