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?

#7

Related question… can you use a parameter in another parameter?

#8

@ndintenfass @rose @KyleTryon (or any Circle employee) We’ve searched through many threads now of users trying to use the “Build only on PRs” feature while also having a few extra branches that are only used for deployments. This article from a while ago mentions this limitation (https://medium.freecodecamp.org/our-journey-for-using-circleci-2-0-to-build-and-deploy-an-angular-app-to-aws-s3-8e7ea3f51503), and these are some of the threads we’ve already come across from trying our own hacks around it (Pull Requests and Multiple Default Branches, Option to enable build on several "default" branches, Option to define default branches in config.yml, Continuing the discussion from Option to enable build on several "default" branches:).

Can you or anyone at CircleCI please offer some advice on how we can get around this limitation? Is there any sort of API that we could use to try to manually trigger things or some experimental feature we may not know about? Our organization is large, and running many extra builds from users that haven’t opened PRs just so we can deploy to a few extra branches is not going to work for us. We were just about to migrate completely from Travis until we hit this limitation and have been at a standstill for a while now. Thanks for your help

#9

@wesleykendall Great question! I don’t think it relates to this topic though?

I’m pretty sure we can help you find a solution—the branch/tag filters we provide for Workflows jobs are fairly robust and flexible.

Can you open a support ticket so we can help you out (feel free to manually CC the folks you tagged here, if you’d like)?

EDIT: oh, I see, it relates to the specific use case the OP was outlining. That said, the approach in that use case (using environment variables in parameters) will not get you where you’re trying to go here, so I still think it’s best to have this conversation elsewhere.

#10

@rose thanks for the speedy response. I went ahead and opened up a support ticket for it. Thanks!

#11

Please let us know if a solution is found/implemented.

#12

@speeddragon what specifically would you like a solution for? What are you trying to do? There are some workarounds here, depending on how you implement things.

#13

It would be nice to have jobs to only run depending of a environment variable, but another solution I think might be:

- run: | 
          if [ "$CI_PULL_REQUEST " != "" ]; then MIX_ENV=test mix coveralls; else return 0; fi' # run all tests in project

I only want to run tests or other jobs if environment variable CI_PULL_REQUEST isn’t empty.

#14

If it’s an entire job, you can use git tags for all your pull requests and then use git tag filters @speeddragon

That said, your other solution sounds like it would work, too.