Using Environment Variables inside Circle.yml

Build Environment
, ,
1

Hi,

I’m setting up a webhook for CircleCI to talk to at the end of every build, but I want to not expose my authentication token to Github. I’ve tried setting an environment through the CircleCI web UI but it doesn’t seem to be working. At first I tried something like “-url: https://www.example.com/endpoint?token=<%= API_TOKEN =>” and that gave me an uncaught exception, I then tried “-url: https://www.example.com/endpoint?token=$API_TOKEN” but that returns a 401 (most likely because API_TOKEN is empty and authentication fails). I have also tried {API_TOKEN} with the same result. What is the correct way to call an environment variable inside the ‘circle.yml’ file, and is setting an environment variable through the Circle CI web UI the correct way to do this?

13 Likes
2

Hey,

Currently, environment variables cannot be used in the webhooks section of circle.yml.

This will be brought up internally. Sounds like a very useful feature to have.

3

It’s a pity.

So I have to put the token in circleci.yml file.

Do you have any other better way to do this?

4

I would like to be able to have my circle yaml look something like
machine: environment: APP_PATH: "testing" notify: webhooks: - url: "https://example.com?appPath=$APP_PATH"
just as good engineering practice, for variable re-use and what not.

2 Likes
5

Any news on this?

6

You can already achieve this with these lines in your circle.yml:

    test:
      post:
        - >
          curl "https://some-service.com?token=${TOKEN}"

I assume this approach works everywhere… as I’m just executing a shell command.
We use this for triggering a jenkins deployment.

    deployment:
      staging:
        branch: develop
        commands:
          - >
            curl "https://${JENKINS_USER}:${JENKINS_PASSWORD}@.../job/.../buildWithParameters?token=${JENKINS_TOKEN}

Works like a charm :slight_smile:

7

Hi,

Has anyone got this working for webhooks?

I tried this:

checkout:
post:
- sed -i “s/KEY/$API_KEY/g” circle.yml

notify:
webhooks:
# A list of hook hashes, containing the URL field
- url: https://my.webook.com?key=KEY

I can see it updates the circle.yml file correctly - but my webhook still gets called with KEY rather than the value… :frowning:

8

Environment variables aren’t parsed for the webhooks section.

9

This greatly diminishes the usefulness of the webhooks, as there’s no way to verify the payload (since it’s impossible to add a secret token as a URL parameter). No secret token means that the web hook can’t trust any of the data received in the payload, as there’s no way to verify that the request actually came from CircleCI. This means the payload is essentially useless and any webhook is going to have to hit CircleCI’s build API to get the data.

Webhooks are still useful, but they must always ignore the payload other than the build number, especially in open-source projects where the circle.yml file is publicly accessible

1 Like
10

I also would like environment variables in webhooks but an alternative way to verify that the request came from CircleCI is to do a GET request and see if the build payload matches up (because webhook notify’s payload should be identical to the Build API)

11

an alternative way to verify that the request came from CircleCI is to do a GET request and see if the build payload matches up

That’s what I ended up doing - I only use the build number from the payload and ignore everything else. I do a GET to their API and then treat that data as the source of truth. It’s annoying to do that though, and it’d be unnecessary if CircleCI just included some sort of private token in the payload.

12

+1 on environment variable support for webhook URLs… this is useful for both API tokens and passing parameters to the webhook

1 Like
13

+1 for having environment variables. I did try to solve a problem with notifications (Formatted Slack message after successful build) through a webhook, just to realise this will not provide me the $BRANCH_NAME variable.

14

+1 on environment variable support for webhook URLs

1 Like
15

Any news on this? I’d like to be able to use environment variables in the path section of store_artifacts as well. E.g.:

- store_artifacts:
          path: $ARTIFACT_DIR
          destination: ./
16

With the release of CircleCI 2.0, can we expect the webhooks section to support one day the environment variables or will it never?

Without being able to use environment variables, I’m really don’t know how this feature can be useful.

Otherwise, I there a place where we can manually make a cURL POST at the really end of a build?

17

I don’t know.

First step is to make sure we have this as a proper feature request. Does this one make sense? If you, " :heart:'ing" the top post will help gauge interest in it.

I do agree that webhooks should have environment variable support. That’s just common sense to me.

18

I’m also looking for a way to get this support. I’d previously been using the webhook element but want to avoid inlining the API key.

I’ve tried using the notification tag with a command element:

notify:
  # The default webhook integration doesn't expand environment variables in the webhook url definition.
  # We workaround this by querying the build info via. the REST API then packaging this result as a notification
  # payload and pushing to OpsGenie.   See https://circleci.com/docs/1.0/configuration/#notify for documentation.
  command: |
    BUILD_INFO=$(curl https://circleci.com/api/v1.1/project/github/$CIRCLE_PROJECT_USERNAME/$CIRCLE_PROJECT_REPONAME/$CIRCLE_BUILD_NUM?circle-token=$CIRCLE_LOCK_API_TOKEN)
    curl -d "{\"payload\": $BUILD_INFO}" -H "Content-Type: application/json" -X POST https://api.opsgenie.com/v1/json/circleci?apiKey=$OPS_GENIE_API_KEY

I’ve manually SSH’d into the Circle pod for the build and the commands work fine when run directly. However they don’t appear to be called when run as part of the regular build file. i.e. CI seems to ignore the command sub-element. Am I missing something or is this WAI?

19

The inability to parse an environment variable in the notify section is disappointing - my project(s) are all open source but my team’s private chat room is not; I really don’t want to post our chat room’s API token into the config.yml file. An env var would be the perfect way to obscure it!

20

I absolutely agree with everyone here, not having the option of using environment variables inside the config makes using CircleCI pretty difficult right now. What is even more frustrating is your lack of communication regarding this. There are several threads where people discuss this issue only to receive a one-line answer that doesn’t solve anything.

edit: typo