Use Environment Variables in Parameters

#1

Hey,

im trying to build a customized “only build PR branches”. This is my config so far

version: 2.1

jobs:
  build:
     parameters:
        should_build:
           type: string
           default: ""
    steps:
      - when:
          condition: << parameters.should_build >>
          steps:
              - do the building here
      - unless:
          condition: << parameters.should_build >>
          steps:
              - run: echo "skipping non PR feature branch"

workflows:
    version: 2.1
    features:
        jobs:
            - build:
                should_build: "$CIRCLE_PULL_REQUEST"

It seems the variable $CIRCLE_PULL_REQUEST is not properly interpolated in the parameters and is always true. I guess its because the config is processed before the parameter injection happens? If i comment the should_build parameter in the workflow job section, it works as expected.

The usecase for is that we have multiple default branches and cant use the “Only Build PR” Switch in the Project settings.

#2

Hi @digitalkaoz,

Please see our environment variables documentation here:

https://circleci.com/docs/2.0/env-vars/#built-in-environment-variables

I don’t believe CIRCLE_PULL_REQUEST will work here in the way you’ve outlined, as it is not a boolean but a URL string.

#3

. I guess its because the config is processed before the parameter injection happens?

You hit the nail on the head. That is exactly the issue here. Environment variables can be used but it depends on the context.

For instance, here they are used in our Slack orb. https://github.com/CircleCI-Public/slack-orb/blob/master/src/orb.yml#L14

The difference is they are executed within the container, not as a part of the config logic.

#4

I guessed that. Any other Idea howto achieve this? Maybe a list of branches that will Bypass the “build PRs only”

#5

In this case you may need to do the conditional inside the shell commands you pass to run because of what Kyle said – the env var won’t be interpolated until you get to the runtime, and all the when logic is performed at config processing time prior to the job running.

#6

Yeah thats not something that is usable. Maybe you can extend this feature to include a list of branches that will always trigger workflows, and do the filtering inside the Workflow?! Also how to run a Workflow for a pull request is openend when no commit is happening on that branch after?