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

Substituting variables into the devfile from the CLI #5489

Closed
2 tasks
feloy opened this issue Feb 23, 2022 · 1 comment · Fixed by #5749
Closed
2 tasks

Substituting variables into the devfile from the CLI #5489

feloy opened this issue Feb 23, 2022 · 1 comment · Fixed by #5749
Assignees
Labels
kind/feature Categorizes issue as a feature request. For PRs, that means that the PR is the implementation

Comments

@feloy
Copy link
Contributor

feloy commented Feb 23, 2022

/kind feature

Which functionality do you think we should add?

Actually, it is possible to use variable substitution on devfile, and the value of the variables comes from the devfile itself (from the .variables part).

It would be helpful to be able to pass values for variables from the CLI, without modifying the devfile.

For consistency, the same behaviour as the --env and --env-file options from docker could be used, by replacing env by var as these are not environment variables. For example:

$ odo dev --var CONTAINER_IMAGE=quay.io/myuser/myimage --var DEBUG=true --var USER
$ odo dev --var-file my-variables.var
$ cat my-variables.var
CONTAINER_IMAGE=quay.io/myuser/myimage
DEBUG=true
USER # this gets the value from the CLI current environment, if defined. If the env var is not defined, the variable is not overriden

AC:

  • for both odo dev and odo deploy commands
  • it should not modify devfile.yaml

Why is this needed?

It seems to be a common use case to create templates to be personalized at run time, similarly to how it is done with helm.

Initial discussion: https://kubernetes.slack.com/archives/C01D6L2NUAG/p1645604581682759

@openshift-ci openshift-ci bot added the kind/feature Categorizes issue as a feature request. For PRs, that means that the PR is the implementation label Feb 23, 2022
@kadel kadel added the v3 label Feb 24, 2022
@kadel kadel removed the v3 label Mar 24, 2022
@feloy feloy self-assigned this May 17, 2022
@kadel
Copy link
Member

kadel commented May 18, 2022

devfile/library#136

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue as a feature request. For PRs, that means that the PR is the implementation
Projects
No open projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants