-
Notifications
You must be signed in to change notification settings - Fork 470
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a dynamic dependancy in order for a test to run #784
Comments
Thanks for the thorough explanation. Reflecting on this, let's approach it from the other end and see where the gaps are. Today goss can leverage external discovery tools as follows:
doc (for the above): https://github.com/aelsabbahy/goss/blob/master/docs/manual.md#examples-2 These tools are dedicated to system discovery and have been around for quite some time, thus having quite a bit of maturity and a rich feature set (ex. pluggability). The same can be said for ansibles fact engine and its plugins. To better understand this enhancement, where do those tools fall short today as an end user? |
Perhaps there's a middle-ground opportunity here:
|
hi @ekelali Thats a great solution. It allows goss to be the one required tool (which is perfect in restricted environments). |
@uk-bolly Does this mean this can be closed now? Should there be a documentation update to show this example? |
There's |
Describe the feature:
Due to the nature and design of many estates some features only exist on certain servers. To make this more dynamic and extendable as well as portable and reuseable. that allows and enables the same config to be run across entire estates rather than individual files per possible server setup.
Problem:
We only need to confirm some server spec if a certain value is true
e.g.
1/ if auditd is installed
2/ then run the following tests.
It could be seen as setting a variable on the fly and ensure the variable value as part of the test. This would also mean certain test would need to run in order. Although as per #742 the subsequent tests may reuse the variable multiple times (example tries to show this too).
This feels more like a programming feature but could extend it usage.
Describe the solution you'd like
A possible way,
add a new option of discovery which runs prior to any other tests to capture and set dynamic variables used by the server spec tests.
These could even be in a dedicated file ensuring that the run before all others.
An example could be (this is very ansible like i am aware)
Example 1
file name: discovery.yml
sometest1.yml
sometest2.yml
Aware this only gives a boolean value rather than a discovered output. It would be nice if you could capture the other outputs and assign a value. e.g.
Example 2
file name: discovery.yml
sometest1.yml
sometest2.yml
Describe alternatives you've considered
This could met by using the command test module, but then that is just running a shell script. It doesn't add the efficiency and consistency in the modules already developed.
Thanks again for this project.
The text was updated successfully, but these errors were encountered: