update dgoss to support imported goss files

[jbgo]

Currently, dgoss doesn't seem to support importing gossfiles via the gossfile test. This happens because dgoss copies goss.yaml but does not copy any imported files to the container. One way to fix this would be to render goss.yaml and copy the rendered result to the container.

Steps to reproduce

Create the following files in the aelsabbahy/goss project root directory.

# file: goss.yaml
gossfile:
  ./included.yaml: {}

# file: included.yaml
process:
  nginx:
    running: true

Then run goss.

./extras/dgoss/dgoss run nginx

Expected result

~$ ./extras/dgoss/dgoss run nginx
INFO: Starting docker container
INFO: Container ID: ab483077
INFO: Sleeping for 0.2
INFO: Running Tests
Process: nginx: running: matches expectation: [true]


Total Duration: 0.001s
Count: 1, Failed: 0, Skipped: 0
INFO: Deleting container

Actual result

~$ ./extras/dgoss/dgoss run -it nginx
INFO: Starting docker container
INFO: Container ID: dafb62d8
INFO: Sleeping for 0.2
INFO: Running Tests
Error: found 0 tests, source: /goss/goss.yaml
INFO: Deleting container

[aelsabbahy]

I like this, the only downside is that it breaks dgoss for OSX, since goss doesn't run on there.

Maybe for now it would make more sense to establish a convention maybe something like:

goss.yaml
goss.d/whatever.yaml

Have dgoss copy goss.yaml and any goss.d stuff over, then run goss validate on the container.

[jbgo]

@aelsabbahy the convention idea is interesting, but it wouldn't really help with the use case I had in mind.

I'm on a team where we have a base docker image and several child docker images that are built from the base image. We have tests for the base image that we also want to hold true in the child images, so we have things set up like this.

~/projects/docker-images/
    base-image/
        Dockerfile
        goss.yml
    child-image1/
        Dockerfile
        goss.yml
    child-image2/
        ....

Then in our child images' goss.yml we have:

gossfile:
  ../base-image/goss.yml: {}

# child-specific tests

We've had issues where installing/configuring something in the child Dockerfile unintentionally reverts a change made in the base Dockerfile and we weren't detecting it until very late in the development cycle (e.g. removing custom certs from java keystore by upgrading java and not re-installing the custom certs).

For now we're working around this issue via a script that basically runs goss render | dgoss run ..., which is working just fine for us now.

On a side note, you mentioned goss doesn't run on OS X. I've got a mac at home and perhaps this is something I could help with. Are there any specific limitations you've encountered with getting goss to work on OS X?

[aelsabbahy]

On a side note, you mentioned goss doesn't run on OS X. I've got a mac at home and perhaps this is something I could help with. Are there any specific limitations you've encountered with getting goss to work on OS X?

The main issue is that goss runs locally on the target machine or the machine under test. So when using dgoss you're running goss in the Linux container. So it's a version of goss that's compiled for linux-amd64 which won't run on OSX.

Today goss doesn't support OSX, I haven't looked into adding OSX support personally. I'm not against the idea so long as it doesn't complicate the code too much to do so. Even then, when using dgoss, you would use OSX goss to run the goss render and linux-amd64 goss to run the goss validate in the container.

Unfortunately, I'm not 100% sure I have a good clean solution that would work for OSX at this point.

The goss render | dgoss run.. approach doesn't seem too bad, I should probably add that to the documentation.

If you have any thoughts on a better approach please let me know.

Thanks,
Ahmed

[aelsabbahy]

Closing this PR since this won't work with OSX.

Updating the documentation with a goss render | dgoss run.. is probably the best approach for now.

Freel free to re-open if you feel otherwise.