goss-org / goss

Quick and Easy server testing/validation
https://goss.rocks
Apache License 2.0
5.57k stars 472 forks source link

dgoss to ignore service enabled #324

Closed JackLeo closed 4 years ago

JackLeo commented 6 years ago

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:

package:
  rabbitmq-server:
    installed: true
    versions:
    - 3.5.0n

service:
  rabbitmq-server:
    enabled: true
    running: true

So this fails with

Failures/Skipped:

Service: rabbitmq-server: enabled:
Expected
    <bool>: false
to equal
    <bool>: true

Whereas passing test:

service:
  rabbitmq-server:
    enabled: false
    running: true

So since docker does not have dbus running, test for service running I assume is skipped, but enabled cannot be tested thus fails.

aelsabbahy commented 6 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.

JackLeo commented 6 years ago

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?

aelsabbahy commented 4 years ago

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.

JackLeo commented 4 years ago

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}}