Hey all, I was testing out 2.0 and the config file seems a great improvement over 1.0, dig it! One problem I was having is that environment variables do not seem to get expanded in several of the paths that are expressed throughout, such as cache directories and working_directory. Is this going to be supported so we can parameterize our aspects of our builds based on environment variables. Thanks!
Yes, evaluating env vars in various places in the config will be supported.
(Something I’m pretty excited to use.)
Any ETA on when this might be available?
Not at this time.
I’ve run into this too. It causes very strange behaviour, as it’s interpolated for checkout, but not for other steps. As such I have a weird directory called
/go/src/$PROJECT_GO_PACKAGE that some steps get stuck in.
The lack of this feature (expanding variables inside the working_directory directive) makes it difficult to produce config files that enable people to just checkout the project and run with it without having to modify anything.
Is there any update on if this feature will be available anytime soon?
Bump!!! No updates here?
bump! Any update here?
I don’t understand the use-case for expanding
working_directory. I have mine set to
/app and that’s it. Why would it be useful to check it out to a dynamic location? I’m thinking something to do with branches (with the branch name being the var) but the container will be clean anyway, so building to a fixed location would be OK.
What’s your use case?
My use case is using golang. Whenever I have a new golang project I have to modify working_directory slightly for things to work. So I’ll have this for one project:
version: 2 jobs: build: docker: - image: circleci/golang:1.9 working_directory: /go/src/github.com/cbdr/project1
and then for project2 I’ll have to change it to be:
version: 2 jobs: build: docker: - image: circleci/golang:1.9 working_directory: /go/src/github.com/cbdr/project2
But it would be nice if I could just specify it as:
version: 2 jobs: build: docker: - image: circleci/golang:1.9 working_directory: /go/src/github.com/cbdr/$CIRCLE_PROJECT_REPONAME
and never need to change it.
Hmm, OK. I wonder if you could use a symlink? So, keep this:
Then when you get to your steps, do this:
command: ln -s /go/src/github.com/cbdr/$CIRCLE_PROJECT_REPONAME /app
I believe you can have env vars in commands, so that might work for you. I’m assuming you would have a custom checkout, in order to clone in a variable location.
Same issue, same context. It would be really nice to have basic variable interpolation in the “working_directory” instruction. Also I would prefer no to add a dirty hack that calls for an extra comment line but rather use a straightforward approach.
Still chasing this. Thanks.
This might give some context: https://github.com/anacrolix/torrent/blob/master/.circleci/config.yml#L10
I don’t work for Circle, but my observation is that post-bumping in the forum isn’t going to hurry the implementation of a feature (product development is probably a bit more involved than that). However, it will probably help to drown out new requests on the front page from other users, so it may be worth contacting Circle another way.