-
Notifications
You must be signed in to change notification settings - Fork 360
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Add environment variables to kpack image CR #1600
Conversation
We have created an issue in Pivotal Tracker to manage this: https://www.pivotaltracker.com/story/show/172550328 The labels on this github issue will be updated when the story is started. |
lib/cloud_controller/kpack/stager.rb
Outdated
}, | ||
build: { | ||
env: staging_details.environment_variables.to_a. | ||
select{ | key, value | key =~ /^BP[A-Z]{0,1}_/ }. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm curious why there is a whitelist on environment variables prefixed with BP*
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This white list is not really required. It was only a gut feeling that feeding in variables like VCAP_SERVICES
could cause problems. We also had these kind of problems when the to_s
was missing in the line below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, VCAP_SERVICES
is not going to be the future method that bound services supply credentials to the app. There is upcoming work for this here - https://www.pivotaltracker.com/story/show/172562308
I think I'd still suggest relaxing the constraint, and maybe only filter out VCAP_SERVICES
. There are many other environment variables that app developers set, and BP*
is overly restrictive (and perhaps too specific to a single buildpack like bellsoft-liberica buildpack).
Hi @aashah , I marked this PR as WIP, because I never filed a PR for cloud controller and I wasn't sure if I needed to run the acceptance tests for this rather small PR. |
Ah yeah, that's totally fine! Definitely agree, CATs is not required for this PR. Once we resolve some of the discussion on that "constraint" in the code, I think I can check out the PR and try it out! |
It also looks like there are several rubocop errors detailed here - https://travis-ci.org/github/cloudfoundry/cloud_controller_ng/jobs/680412878 |
Hi @aashah, I removed the select for the variables starting with BP*. |
Hey @kramerul, I think your original gut feeling around wanting to prevent Additionally, there are many silly rubocop errors that need to be taken care of before I can merge the PR - https://travis-ci.org/github/cloudfoundry/cloud_controller_ng/jobs/681337312
|
Hi @aashah, I'm now filtering out |
Looks good to me! Dev acceptance:
|
* In the original PR (#1600), we only applied environment variables when creating the first "Image" resource [#172301179] Authored-by: Aakash Shah <ashah@pivotal.io>
Thanks for contributing to cloud_controller_ng. To speed up the process of reviewing your pull request please provide us with:
See
Env variables are not passed to kpack builds
Links to any other associated PRs
I have reviewed the contributing guide
I have viewed, signed, and submitted the Contributor License Agreement
I have made this pull request to the
master
branchI have run all the unit tests using
bundle exec rake
I have run CF Acceptance Tests