Disable Docker CLI hints

[davidkopp]

Fixes #554

I have chosen the option to disable the Docker CLI hints via the environment variable DOCKER_CLI_HINTS=false in the current session.

Another option could be to permanently disable them in the Docker settings ($HOME/.docker/config.json):

"plugins": { "-x-cli-hints": { "enabled": "false" } }

[ribalba]

Brilliant thank you so much for this PR. I really like the idea of telling docker to be less verbose. Just taking a very quick look I am wondering if this will really catch all cases we call docker. I didn't know that if you call subprocess.run without shell=True it would pass in the env vars from the shell that called python. I am just thinking if this opens up any security implications in the long run as someone could inject env vars into processes that run as root. So for now this PR looks ok for me but we should maybe think this a little bigger on how we want to handle env vars in general.

@ArneTR I would merge for now and then we can write an issue how to maybe use the env parameter in the subprocess.run calls to make sure that no one can inject something which for now is not really a problem as nothing we call should be modifiable by env vars.

[0] https://docs.python.org/3/library/subprocess.html

[ArneTR]

That the environemnt is passed to the child process is mandatory. For instance if Docker runs in rootless mode it must know where to find the socket. The CLI command would fail if DOCKER_HOST was not set.

I also see no security implication by how we currently handle child process generation. The only custom code we allow should run inside the docker containers that are created.
Never should code of the user be run on the host system itself.

So in conclusion: I see setting env={} as more more problematic than helpful.

2. To my suprise my docker also CLI hints enabled and I see the messages of kaniko, but it does not fail my tests ...
   Neverthelesse turning off this option is definitively what we want.

[ArneTR]

Actually just as I wrote the post before something came to my mind: I wonder how this PR is working for the tests ...

The tests mirror the flow of the runner.py by creating mimic code. See https://github.com/green-coding-berlin/green-metrics-tool/blob/a2b2ceda9ba8599b3985185e5ceae73fa2062380/tests/test_functions.py#L69

If you do not also call the new "step" of the runner there the addition of the ENV var will not be executed in the test.

@davidkopp Could it be that you have the ENV var set in your system in the shell already that you call the python process for the tests from? Otherwise I would not know why the tests should behave differntly.

If so: Could you please add the line "prepare docker" also in the test_functions.py

[davidkopp]

Only the tests were failing that executed runner.py directly.
Example:

ps = subprocess.run( ['python3', '../runner.py', '--name', RUN_NAME, '--uri', uri ,'--config-override', 'test-config.yml', '--skip-system-checks', '--dev-repeat-run']

The tests that are using Tests.run_until didn't fail, because they never came to the point where Docker printed the problematic CLI hints.
Example:

Tests.run_until(runner, 'setup_services')

Nevertheless, I have now added my change also to test_functions.py.

[ArneTR]

lgtm. ty!

running tests

[ribalba]

The test failed with some docker problem. Rerunning to check if it was a networking issue