.circlerc, $BASH_ENV, $ENV

Build Environment
1

Are there any plans to add back in to 2.0 the ability to have a file executed or sourced with each build step? In 1.0 I’ve used both the .circlerc file and the file pointed to by $BASH_ENV to do this. With the Alpine builds and version 2.0, there is now no way to accomplish this without manually sourcing my files in every step.

2

I don’t believe so.

Using $BASH_ENV on the official Alpine images don’t work because Bash isn’t pre-installed. You can use any image that has Bash pre-installed, or install it yourself runtime and change the shell that’s used. Here’s an example of how that last option could work:

workflows:
  version: 2
  main:
    jobs:
      - build


version: 2
jobs:
  build:
    docker:
      - image: alpine:3.8
    steps:
      - checkout
      - run: |
          apk update && apk add bash
      - run:
          shell: "/bin/bash -eo pipefail"
          command: |
            echo $BASH_ENV
            echo 'export TEST_VAR="chicken"' >> $BASH_ENV
            cat $BASH_ENV
            echo $TEST_VAR
      - run: 
          shell: "/bin/bash -eo pipefail"
          command: |
            echo $TEST_VAR
3

Thank you for the response. I do understand that option. However it requires me to redefine the shell on every run command. We’re trying to manage over 50 complex services with CircleCI so we’re quite interested in keeping things as standard and simple as possible. Many of our build scripts are quite complex with several external integrations and lots of steps.

I’m trying to avoid updating our runbooks to instruct our dev teams that they now need to put this on every step.

I’m open to pretty much any option here that will allow us to define this once somewhere (anywhere) and have it work properly. I realize you’re depreciating 1.0, but still holding out hope that you’ll provide some alternative solution to allow 2.0 to have a similar capability.

I realize sometimes old features need to be sunset in order to make room for new plans. However, removing this quite flexible and very useful feature (sourcing a file before build steps) doesn’t seem to serve any purpose (although I acknowledge that I don’t have the inside scoop on why this was removed).

4

If you can use the multi-line format of the run step, adding in another line doesn’t seem too onerous. You could even have a quick linter to ensure it is present in every step:

  - run:
      name: Save Docker image layer cache
      command: |
        sh /tmp/run-me.sh
        mkdir -p /caches
        docker save -o /caches/${CIRCLE_PROJECT_REPONAME}.tar ${CIRCLE_PROJECT_REPONAME}

Adding that run-me.sh manually doesn’t seem to harm readability too much?

5

Well I mentioned two options. 1 is to define the shell each time, which I agree, isn’t great. I was just letting you know you can.

The other option is to use a Docker image with Bash pre-installed.

6

Thanks folks, I appreciate the consideration and feedback. Our builds each consist of several run steps due to the modular nature of how we build and deploy software. None the less, I understand the options presented here. I’d still respectfully propose that this should be on the roadmap somewhere (I’ll put a message in the feature request channel). Thanks again.

7

No problem. You’ll want to use https://circleci.com/ideas.

8

If you always need the same yaml config in multiple places, you can use yaml anchors.
There is also a reusable code option in the upcoming v2.1 (orbs)
While neither of these solve your issue directly, they could help with you creating a workaround

9

What base image are you using, @mtwomey? You could create a new Dockerfile that inherits from this, and puts Bash in place, so that Bash-specific features work.

10

We use several different base images - we’re managing a couple of hundred repositories right now and have around 50 active services. In general we tend to use several of the node images and most recently the docker:17.11.0-ce-git image. We enjoy not having to maintain derivative images ourselves - but yes, that would be something we could do. Thanks, I’ll add that to our options list.

1 Like
11

I am also curious if there is a “downside” to souring a file when containers spin up (as was done with .circlerc in v1.0). Not sure if anyone in this thread has any insight into this? E.g. were there issues with doing this, was it troublesome as a feature to carry forward, was it just sort of “not in anyone’s thoughts” while 2.0 was being developed?

12

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.