Skip to content
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

Environment variables for a specific command #21

Closed
l0rd opened this issue Feb 6, 2020 · 8 comments · Fixed by #35
Closed

Environment variables for a specific command #21

l0rd opened this issue Feb 6, 2020 · 8 comments · Fixed by #35
Milestone

Comments

@l0rd
Copy link
Contributor

l0rd commented Feb 6, 2020

Should it be possible to set environment variables that apply for a specific command? The current way to handle this would be to set the environment variables inline with the command but this can be cumbersome and reduce readability.

Sample of current devfile snippet to show example of usage/format:

- exec:
     commandLine: "MAVEN_CONFIG=~/mvn/config JAVA_OPTS="-XX:MaxRAMPercentage=50.0 -XX:+UseParallelGC -XX:MinHeapFreeRatio=10
               -XX:MaxHeapFreeRatio=20 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90
               -Dsun.zip.disableMemoryMapping=true -Xms20m -Djava.security.egd=file:/dev/./urandom
               -Duser.home=/home/user" ./buildSchema.sh"
     component: build-tools
     alias: buildSchema

Example with proposed changes:

commands:
 - exec:
     commandLine: "./buildSchema.sh"
     env:
     - name: MAVEN_CONFIG
       value: "~/mvn/config"
     - name: JAVA_OPTS
       value: "-XX:MaxRAMPercentage=50.0 -XX:+UseParallelGC -XX:MinHeapFreeRatio=10
               -XX:MaxHeapFreeRatio=20 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90
               -Dsun.zip.disableMemoryMapping=true -Xms20m -Djava.security.egd=file:/dev/./urandom
               -Duser.home=/home/user"
     component: build-tools
     alias: buildSchema
@l0rd l0rd mentioned this issue Feb 6, 2020
28 tasks
@l0rd
Copy link
Contributor Author

l0rd commented Feb 6, 2020

cc @johnmcollier @elsony

@davidfestal
Copy link
Collaborator

That would be very easy to do, model-wise, and quite consistent with the way environment is mentioned in other parts of the devfile (in container components for example).

@l0rd
Copy link
Contributor Author

l0rd commented Feb 25, 2020

Reviewed and approved

davidfestal added a commit that referenced this issue Apr 3, 2020
Signed-off-by: David Festal <dfestal@redhat.com>
davidfestal added a commit that referenced this issue Apr 22, 2020
* Implement agreement on issue #18
* Implement agreement on issue #17
* Implement agreement on issue #21
* Implement agreement on issue #22
* Implement agreement on issue #27
* Implement agreement on issue #9
* Implement agreement on issue #10
* Fix PR comments about issue #9 PR comment #35 (comment)
* Fix PR comments about issue #17 PR comment #35 (comment)
* Implement agreement on issue #14 and  #19
* Add the spring boot example
* Implement agreement on issue #32
* Fix last PR comments

Signed-off-by: David Festal <dfestal@redhat.com>

Co-Authored-By: Sergii Leshchenko <sleshche@redhat.com>
@maysunfaisal
Copy link
Member

I am wondering what is the benefit of doing this way as opposed to having the ENV defined for the component container?

Also what happens if multiple commands are referencing the same component and require the same ENV? Will I need to mention it twice in the respective command? That seems redundant IMO..

@johnmcollier
Copy link
Member

johnmcollier commented May 6, 2020

@maysunfaisal This allows you to easily set variables for just one command, without needing to change the default value for the entire container, and to allow separate commands to have separate values for the same variable.

The environment variable value will only be set in the context of the command, and shouldn't conflict with other commands setting the same variable.

The example given in issue description is a good one, setting different values of JAVA_OPTS for each separate command as needed.

@maysunfaisal
Copy link
Member

maysunfaisal commented May 6, 2020

@johnmcollier will 2.0 spec support defining ENV on the component level as well or just on the command level?

@johnmcollier
Copy link
Member

@maysunfaisal Both

@l0rd l0rd added this to the 2.0.0 milestone Jun 16, 2020
@davidfestal davidfestal linked a pull request Jun 22, 2020 that will close this issue
@davidfestal
Copy link
Collaborator

Implemented

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants