Skip to content
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

Resource `git` actions `checkout` and `sync` abend in a Dokken environment: no /dev/tty #8855

taqtiqa-mark opened this issue Aug 30, 2019 · 3 comments


Copy link

commented Aug 30, 2019


Resource git actions checkout and sync abend in a Dokken environment: no /dev/tty

Chef Version

Chef Development Kit Version: 3.11.3
chef-client version: 14.13.11
delivery version: master (9d07501a3b347cc687c902319d23dc32dd5fa621)
berks version: 7.0.8
kitchen version: 1.25.0
inspec version: 3.9.3

Platform Version

Ubuntu 18.04

Replication Case

When Dokken testing the git resource as follows:

33:   git "Install #{} plugin" do
34:     destination ::File.join(root_path, 'plugins',
35:     repository new_resource.git_url
36:     reference new_resource.git_ref
37:     user new_resource.user if new_resource.user
38:     action :checkout
39:   end
40: end

Client Output

I encounter an issue as described on SO.

The error is:

* git[Install julia-build plugin] action checkout

Error executing action `checkout` on resource 'git[Install julia-build plugin]'

Expected process to exit with [0], but received '128'
---- Begin output of git ls-remote "" "master*" ----
STDERR: fatal: could not read Username for '': No such device or address
---- End output of git ls-remote "" "master*" ----
Ran git ls-remote "" "master*" returned 128

I was able to test and confirm that in the Dokken environment:

echo ahoj > /dev/tty
bash: /dev/tty: No such device or address

It appears the issue is here?

This appears to be confirmed by the fact that the git unit specs require (stub) tty? to return true.
If this is not going to be fixed, then at least the resource should abend with an error message that a tty is required.


As Above.


This comment has been minimized.

Copy link

commented Aug 30, 2019

I believe the correct way to accomplish this is git show-ref --quiet --verify <ref> >/dev/null 2>&1, redirecting stderr and stdout to /dev/null and returning the result depending on the exit code?

Before I sink more of my time. Would you accept a pull request implementing this approach?

taqtiqa-mark pushed a commit to taqtiqa-mark/jlenv-cookbook that referenced this issue Aug 30, 2019
Refactor unit & interation tests
Commitng these changes in order to move to
monkey patching the git resource revision
logic to over come chef/chef/issues/8855

Policyfile referencing was difficult to get
stabilised for both unit and integration tests.

This comment has been minimized.

Copy link

commented Aug 30, 2019

yeah although 2>&1 is a bash-ism and it needs to work if the shell is tcsh, and probably needs to work on windows as well.

if there's a way to pass the moral equivalent of ssh's -n argument to git that would be better rather than trying to convince mixlib-shellout to wire up /dev/null in a shel-portable-fashion and do <something that i couldn't guess> on windows, which is probably going to be a lot harder.


This comment has been minimized.

Copy link

commented Sep 2, 2019

@lamont-granquist thanks for looking at this.
Agreed. I've been thinking about this a little more.

The absence of a TTY is the default in many of my chef-automated use cases i.e. cloud server setup's, containers, etc.
From my perspective (and reading around), issues such as this one are circumvented by:

  1. using vagrant,
  2. passing docker a --device or
  3. avoiding such stdout/stderror parsing recipes.

In my case I'm making more use of dokken, and here I can't sidestep the git resource.

Rather than piping to stdout and stderr it seems the more generic approach is to send the data to files and read it from there.

Question: Is there an example of the best-practice Chef way to write/read temp files in a recipe?
Answer: Use the live_stdout/live_stderr in mixlib's shell_out(...) as instances.

In this case the process would be git show-ref --quiet --verify to get the result/return code.
If the return indicates verified then read in the output file generated.

This (no tty) seems to be an issue more widespread than the git resource?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.