If you've used environment variables in CircleCI you'll know the pain of a horrible 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 like SUPPORT_CONTACT=sendspam@public-email.com will only be seen again by in CircleCI Settings UI as SUPPORT_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.1 jobs: getout: steps: - run: command: | mkdir -p /tmp/ env >> /tmp/circleci.env - store_artifacts: path: /tmp/circleci.env destination: artifact-file workflows: workflow: jobs: - wantout: name: getout context: - 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 your contexts 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 been proven 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 by Dan Schiumarini
Top comments (0)