ddev: Add option to not display result of `ddev exec`
Is your feature request related to a problem? Please describe.
I am working on adding [support for DDEV on GrumPHP (https://github.com/phpro/grumphp/pull/972/files)
At the moment ddev exec outputs the command that failed to execute, either in full or in json with ddev exec -j.
Full Output of a failing commit
JSON Output of a failing commit
Describe the solution you’d like
I’d like a ddev exec option to not output anything, GrumPHP will be red or green anyway and that’s all the verbosity that is required.
Something like ddev exec --no-output COMMAND
Describe alternatives you’ve considered
Run git commands from inside the container, but it is not really an option because one would have to copy over ssh keys, git config (easy) and gpg keys (I don’t know how to do this yet).
Additional context Grum seems to be widely adopted. If we manage to get https://github.com/phpro/grumphp/pull/972 in a good state it would mean out-of-the-box support for DDEV. PR over there is working at the moment, though I’d 'love to improve it to run both inside and outside of ddev containers.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 44 (12 by maintainers)
Commits related to this issue
- #3518: Supress feedback on command failure — committed to bserem/ddev by bserem 2 years ago
- Add option to supress error-messages (#3518) — committed to bserem/ddev by bserem 2 years ago
Issue related to that is https://github.com/moby/moby/issues/31706. If I recall correctly, the root cause for that is that on Linux
stdoutis “buffered”, butstderrnot. Docker collects data from both, but due to one of them being buffered, output may not appear directly and because of that appear out of order.It seems to me like this either got solved or isn’t useful in most workflows, but I’m going to close this for now, happy to continue the conversation here or elsewhere.
@gilbertsoft apparently @bserem wasn’t just bothered by the return code - I think we talked about that at length. It was the actual stderr output that bothered him.
Your existing symlink could never work anyway, because it was trying to reach into the host when it’s being used in the container. In the future, you’ll want to copy your .gitconfig in there.
You have something very, very wrong going on there, maybe it’s an obscure bug or something. But…
cp: '/mnt/ddev_config/.homeadditions/./.gitconfig' and '/home/bserem/./.gitconfig' are the same filemeans that perhaps you have used a symlink for your .gitconfig? Or… ???
I’d love to know how you created this. It’s trying to copy /mnt/ddev_config/.homeadditions into the /home directory and it’s finding they’re the same file. That means a link of some type has been used.
If you just remove the .gitconfig that you have placed in either ~/.ddev/homeadditions or
<project>/.ddev/homeadditionsit will solve this, but I don’t know how you can even get this.@bserem I felt so, too. But it is actually pretty easy. After checking out the ddev repo or your fork you just run
make. The newddevbinary is then in.gotmp/bin/*/ddev. That is totally isolated and does not affect your normal installation. For testing,ddev poweroffyour normal installation and<path to ddev-git>/.gotmp/bin/*/ddev startyour test project. If you want to make sure that there are really no side effects,<path to ddev-git>/.gotmp/bin/*/ddev poweroffwhen you are done.I’ve seen it, I’ll test it on Monday. Sorry for the delay
Maybe the option should be called
--no-error-outputor maybe we should get rid of the additional error output entirely @rfay ?