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)