If you've used environment variables inCircleCI you'll know the pain of ahorrible UI. Once a variable is added you can"never" see it again (you can't even edit it blindly - you need to delete the entire entry and re-add it - key & value).

CircleCI also has no differentiation between a variable and a secret. A basic public var likeSUPPORT_CONTACT=sendspam@public-email.com will only be seen again by in CircleCI Settings UI asSUPPORT_CONTACT= xxxx.com or worse************** if you attempt to echo it in your build logs. This makes it über hard to know what's being used in your builds and is a "great" [sic] form of lock-in when you attempt to move away from CircleCI. Here's a little script I devised for this very purpose which hasn't been blocked...yet.

version:2.1jobs:getout:steps:-run:command:|mkdir -p /tmp/env >> /tmp/circleci.env-store_artifacts:path:/tmp/circleci.envdestination:artifact-fileworkflows:workflow:jobs:-wantout:name:getoutcontext:-org-global-my-context

The script above will dump all the env vars exposed to the running job into a file which will be added as an artifact. You can then download the text file from the CircleCI webUI (Pipeline > Workflow > Job).

You will need to list the name(s) of yourcontexts to expose their variables to the job. If you don't use contexts you can remove the last 3 lines of this snippet.

Ensure you rotate your secrets as this leaves a nice dump of secure items in what's likely a very insecure file storage location, on the infrastructure of a company that's beenproven to be insecure in the past 😉 Also your personal computer is also not a good place to leave secrets (this is how CircleCI got themselves exposed).

PS: for a vastly superior "envvar" UX, checkout how GitHub Actions do it - much more control and visibility.

Cover image byDan Schiumarini