Add the ability to run dgoss when the docker daemon is not local.

[plispe]

I created pull request which is discussed in #269 and #243. All the changes should be backwards compatible.

[aelsabbahy]

I'm guessing the #243 link was a mistake.

Skimmed through the code and I like this approach. I'll test it and provide feedback this week.

[plispe]

Yes, #243 link was a mistake. Sorry I meant #246.

[elliotweiser]

mount or copy

[plispe]

@elliotweiser Ok I will change cp to copy. I used cp only because the docker cp subcommand.

[aelsabbahy]

Cp is fine, I think it's the "of" instead of "or" that needs fixing.

[plispe]

yes. "of' is a typo. sorry for that.

[elliotweiser]

Yep just a typo: I meant of vs or.

Whatever your preference is for copy vs cp ;)

[elliotweiser]

Sorry about that... my brain did an auto-complete 😅

[elliotweiser]

It should be possible to copy the goss.yaml file out of the running docker container when using the copy option, no?

[plispe]

@elliotweiser I think, that goss.yaml is copied only when you use dgoss edit not when dgoss run is used. The dgoss edit should work as expected.

[elliotweiser]

You are correct about the goss.yaml not being copied out of the container when using dgoss run.

I guess I'm responding to this statement:

With the 'cp' strategy you lose the ability to write tests or waits against the docker output.

Since the generated goss.yaml would normally live on the volume, retrieving it after dgoss edit is trivial. When using the cp mode, I think the original behavior can be preserved by executing a docker cp <CONTAINER>:<file> <file>.

(I personally can't think of a good reason for developing tests against a remote docker daemon, but for the sake of thorough code review, I thought I'd point this out).

Overall, LGTM 👍

[plispe]

Since the generated goss.yaml would normally live on the volume, retrieving it after dgoss edit is trivial. When using the cp mode, I think the original behaviour can be preserved by executing a docker cp :file file.

There is actually no volume used with dgoss edit but, the generated goss.yaml is copied with docker cp command from the container. Therefore dgoss edit is unaffected by my changes.

With the 'cp' strategy you lose the ability to write tests or waits against the docker output.

This statement is about the following command from dgoss script docker logs -f "$id" > "$tmp_dir/docker_output.log" 2>&1 & whose behaviour can not be preserved with cp strategy. Because you have no possibility to stream docker log -f output to the running container without a mounted volume.

[elliotweiser]

I stand corrected: dgoss edit indeed doesn't use docker volumes. In which case...

!

[plispe]

@elliotweiser

(I personally can't think of a good reason for developing tests against a remote docker daemon, but for the sake of thorough code review, I thought I'd point this out).

The only use-case could be the use of CicleCI Debugging Jobs Over SSH as CircleCI runs jobs in separated environments. I debug sometimes my failed builds over ssh.

The reason for this PR was actually the fact, that dgoss does not run with CircleCI at this time.

[elliotweiser]

Neat! I'll have to check that out. Thanks for the contribution and the thorough responses!

[plispe]

You are welcome.

[aelsabbahy]

Apologies for the delay on this, looks great. Thanks for the contribution!

[plispe]

No problem. I used my fork untill now. Thanks for merge.