-
Notifications
You must be signed in to change notification settings - Fork 61
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
Top level attribute definition in a devfile #239
Comments
The logic on replacement of the attributes needs to be part of the API implementation. |
Since a child and a parent could each define a given attribute with a different value, it seems like we'd have to define the order of global attribute substitution vs. child/parent merge. It seems like we might need to do the global attribute substitution in the child first if we need to use the value in order to reference the parent. At that point, when we merge in the parent, we'd need to merge the global attributes of the child + parent (child overriding) to resolve substitutions in content coming from the parent. |
The attribute should have the same overriding rule as the rest of the other elements:
If we stick to these generic overriding rules, then we can just merge the parent and child first and then do the attribute substitution on the merged model. |
For the record, here is a summary of what we are going to do for the top-level free form attributes, global string variables, and the existing attributes in the metadata: #352 (comment) |
@elsony I think we should rename the issue title, since this logic is for variables. And open one more for top level attributes for a historical perspective? |
The existing devfile does not have a way to define global attributes. If there are some values that I wanted to reuse in different sections of the devfile, I need to repeat those values in various places within a devfile.
Sample use case:
I wanted to create a couple of maven stacks and all of them have pretty much the same content except that the commands/images will make use of a different version of java. If I can define global attributes in a devfile, I can use the attribute key in places where I need to reference the java version, e.g. image path, commands, etc. Then, I can just have a single parent for those maven stacks and each child devfile of them just override the java version attribute in the devfile to provide the specific java version behaviour in different stacks.
Proposal:
{{attribute-name}}
to refer to the attribute with the keyattribute-name
Example:
This example defines a global attribute java version number on the top level and references the value of the variable in the container image field.
Note: Using this mechanism, we can also address the requirement #149 where each container can refer to the global attribute value and add the required environment variables in the container definition.
The text was updated successfully, but these errors were encountered: