Rename 'CI' environment variable to 'COMPLEMENT_IN_DOCKER' or similar

[anoadragon453]

This grew out of a discussion here, where it was found that the CI environment variable is used by Complement to know whether it is running inside of a docker container already (and thus needs to talk to the host's docker socket) or is running on the host directly. It's assumed that if Complement is running inside of docker, CI=true.

@richvdh proposed to rename this variable to COMPLEMENT_IN_DOCKER (or something similar) instead, as it's more descriptive of what the variable actually specifies. Plus people won't be tempted to add CI-specific things outside of what's necessary (and thus making CI code split further from production code) 😇.

[kegsay]

I chose CI=true because

• Gitlab runners do it https://docs.gitlab.com/ee/ci/variables/predefined_variables.html
• Travis CI does the same https://docs.travis-ci.com/user/environment-variables/#default-environment-variables
• As does Buildkite https://buildkite.com/docs/pipelines/environment-variables#bk-env-vars-ci

[richvdh]

right, but the feature you're enabling here isn't "running under CI", it's "running under docker".

• there's no reason why I shouldn't do this stuff locally as well as under CI.
• there's nothing to say that if I'm running under CI, I'm inherently running inside a docker container. Sure that's the approach we take on our BK setup but other CI envs might solve the problem completely differently.
• calling it CI tells me, as a complement user, absolutely nothing about what difference it makes, making it a scary black box.
• calling it CI means that I might be tempted to make complement do other things differently under CI than in a normal run, which is generally a bad smell.

All in all: I think you chose ... poorly :)

[kegsay]

I agree with your concerns and I'm not opposed to updating the name, but this was my thinking at the time.