This forced masking of all environment vars without an opt-out whitelist is an anti-pattern.

There's a difference between secrets and environment variables, however other than where they're generated they are now treated exactly the same.

Seeing environment variables allows us to print instructions for our engineers to run failed tests locally instead of through CI. This is a major use case for us.

Give the option to completely mask a value (like passwords) or leave it completely visible. Azure has it, Octopus deploy has it, wouldn't hurt if CircleCI had the same implementation. This half shown values are absolutely useless.

It seems that this security measure was implemented in something of a cack-handed way (clumsy, awkward). I am currently trying to control my builds using 'infrastructure as code' type processes which means a lot of environment variables are being passed into the build process and the resulting running environment as tests are performed. The result is that all I see is a sea of '*' characters in the log files.

Not all environment variables are secrets - for my environment, they are often just variables that detail a docker repo, container or version. Currently, I lose all this detail in my logs.

The logical solution would be to have a flag that can be set at the run command level to turn this processing off when needed. The current solution of asking for the feature to be disabled at the project level is just as cack-handed as some variables are secrets.

This is very frustrating when trying to debug orbs

Please, add support for whitelisting individual env variables. It's common to have things like company name, or the environment name (i.e. test/dev/staging/etc) in an env variable, which then completely messes up output, breaks URLs etc.

any news on it?

+1, this is incredibly intrusive, if you have your repo name in an env variable it breaks any generated urls that use it. Why can't this be set at least at a job level? This has been causing problems for quite a while, it would be nice to have an official response

We have a similar use case like Erik describes.

We use context heavily to switch our commands/jobs to do the right thing. This means that we have a dev, acc & prod context and they contain variables like GOOGLE_PROJECT and GOOGLE_GCLOUD_KEY.

The key obviously should stay hidden, but in logs, it's really hard to see which GOOGLE_PROJECT it is trying to use, since that is masked as well.

This is a real need for my team. I'll consider other vendors if this is not addressed.