Closed JackLeo closed 4 years ago
You can put the test behind a conditional. Then pass in something like -e IN_DOCKER=true
For conditionals see: https://github.com/aelsabbahy/goss/blob/master/docs/manual.md#templates
If the test expects a service to be running and it's not, Goss will fail, it doesn't skip.
ah Since there is no upstart/systemd there is still initd scripts. Initd does work within docker as /etc/init.d/rabbitmq-server status does return.
So then enabled is checked via upstart/systemd whereas status also uses initd?
Did you ever find a resolution for this?
For init: Goss checks for the existence of this file: https://github.com/aelsabbahy/goss/blob/f48894934e3d63cdb6aeedcac3f5e14884c50327/system/service_init.go#L62
For running check, it checks this command: https://github.com/aelsabbahy/goss/blob/f48894934e3d63cdb6aeedcac3f5e14884c50327/system/service_init.go#L53
You can check service_driver.go for different drivers that are supported by goss and how they check.
In the end, I had used separate tests for docker/vmi as you suggested as that seemed like the simplest solution. Inclusion of the variable is something that can be done in a few ways though. I chose to bake it into the base Dockerfiles as it's quite a useful behaviour for other checks as well.
{{if getEnv "INSTALL_ON_DOCKER"}}
service:
service-of-interest:
enabled: false
running: false
{{else}}
service:
service-of-interest:
enabled: true
running: true
{{end}}
As commented in https://github.com/aelsabbahy/goss/issues/323 I am running the same test suite against a container as well as the docker image to validate the automation and reduce the feedback cycle.
I am running these tests:
So this fails with
Whereas passing test:
So since docker does not have dbus running, test for service running I assume is skipped, but enabled cannot be tested thus fails.