Right now, each YAML test file has only one set of file contents and expectations, e.g.:
data-root:
files:
sos_commands/dpkg/dpkg_-l: |
ii keystone 2:17.0.1-0ubuntu0.20.04.1 amd64
var/log/keystone/keystone.log: |
Traceback (most recent call last):
Fabulous error
raised-bugs:
https://bugs.launchpad.net/bugs/1896125: >-
Found a bug
If we were to test this for multiple versions of the Keystone package, we would need to create separate YAML files for every single version, for both "should raise stuff" and vice-versa cases. It would be less cumbersome to do so if the test YAML syntax had a way to express alternatives for each file or condition, like the following superficial syntax:
lp1896126-should-raise.yaml:
data-root:
files:
sos_commands/dpkg/dpkg_-l:
- ii keystone 2:17.0.0-0ubuntu0.20.04.1 amd64
- ii keystone 2:18.0.0-0ubuntu0.20.04.1 amd64
- ii keystone 2:19.0.0-0ubuntu0.20.04.1 amd64
var/log/keystone/keystone.log: |
Traceback (most recent call last):
File "/usr/lib/python3.10/contextlib.py", line 135, in __enter__
return next(self.gen)
File "/usr/lib/python3/dist-packages/ldappool/__init__.py", line 391, in connection
raise MaxConnectionReachedError(self.uri)
ldappool.MaxConnectionReachedError: ldaps://ldapserver.example.com
raised-bugs:
https://bugs.launchpad.net/bugs/1896125: >-
Found a bug
lp1896126-should-not-raise.yaml:
data-root:
files:
sos_commands/dpkg/dpkg_-l:
- ii keystone 2:17.0.1-0ubuntu0.20.04.1 amd64
- ii keystone 2:18.0.1-0ubuntu0.20.04.1 amd64
- ii keystone 2:19.0.1-0ubuntu0.20.04.1 amd64
var/log/keystone/keystone.log: |
Traceback (most recent call last):
File "/usr/lib/python3.10/contextlib.py", line 135, in __enter__
return next(self.gen)
File "/usr/lib/python3/dist-packages/ldappool/__init__.py", line 391, in connection
raise MaxConnectionReachedError(self.uri)
ldappool.MaxConnectionReachedError: ldaps://ldapserver.example.com
raised-bugs:
# none
Right now, each YAML test file has only one set of file contents and expectations, e.g.:
If we were to test this for multiple versions of the Keystone package, we would need to create separate YAML files for every single version, for both "should raise stuff" and vice-versa cases. It would be less cumbersome to do so if the test YAML syntax had a way to express alternatives for each file or condition, like the following superficial syntax:
lp1896126-should-raise.yaml:
lp1896126-should-not-raise.yaml: