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