-
Notifications
You must be signed in to change notification settings - Fork 201
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
Suggestion: Set custom values during porter build #1789
Comments
Hi @carolynvs , I want to ask some clarification questions if I may:
|
We don't explain this explicitly in our CLI documentation but some of our commands are so common, like If you run As for the |
@carolynvs Ah yes, I forgot about aliases, that explains 😅
By the way I'm sorry if I haven't fully got it yet, from the example that you mentioned above does this mean that the So does this mean that it will be like below for the particular command?
|
@joshuabezaleel Yup! The example you have there is what we want. Any custom values should be applied to the porter.yaml (there is already an existing bit of code that handles editing the porter.yaml before the build and saving it to .cnab/app/porter.yaml). Then at runtime, the existing templating mechanism handles injecting the value "0.2.0" when actions from the manifest are executed (like the helm install step). |
@carolynvs May I ask to be assigned for this one? Will put up a PR tomorrow 🙌 |
Assigned! I noticed in your example above that you didn't mention the Dockerfile. I wanted to call out that in addition to injecting the custom variable into the porter.yaml, the value is also injected into the docker image when it is built using a build argument. In the original example I posted, we have a custom variable named "version". So when the invocation image for the bundle is built we should pass a build argument named "CUSTOM_VERSION". One scenario to consider is how to inject a nested custom variable. porter.yaml custom:
myapp:
version: "placeholder" command executed
final porter.yaml custom:
myapp:
version: "0.2.2" Dockerfile ARG CUSTOM_MYAPP_VERSION Note that the dot Another note about types. Someone should be able to set a boolean or numeric value in addition to a string (let's ignore setting an entire object value for now). So custom:
active: true # true is a boolean, not a quoted string Same for numbers, custom:
number: 5 # 5 is a number not a quoted string |
@carolynvs I almost forgot about the Dockerfile, thank you for the kind reminder, Carolyn! I am sorry in advance if it's going to take a little longer since I forgot about this one 😅 Where should the custom input arguments be located inside of the Dockerfile? Let's say I'm using the
|
You don't need to change the Dockerfile at all! 🎉 The bundle author will declare and use |
@carolynvs Ah yes, what I meant by changing the Dockerfile was actually by passing the custom values as the |
@carolynvs Another thing that I want to ask for help and need to consult is regarding the variable type handling. I stumbled upon these and it's been days since I haven't found any good workaround 🤔 . I noticed that the
Along with the comment I attached the recording of the prototype that shows what I described on the 3 points earlier. Please pardon all of the logs that I used to debug 😅 porter-1789-custom-values-porter-build.1.mp4Truly sorry for the trouble and thank you so much in advance, Carolyn! 🙂 |
Porter supports two different build drivers: standard docker and the new docker buildkit. So you will need to add support for passing build arguments in both implementations. |
As for the type stuff, I think my use of quotes was confusing. Let's step back and think about what will happen in each case for various types and how we can avoid caring what type they specified for a variable. string# the command --custom myvar=something yields the following porter.yaml
# myvar will be treated like a string by porter when it reads the yaml file at runtime.
custom:
myvar=something boolean# the command --custom myvar=true yields the following porter.yaml
# myvar will be treated like a boolean by porter when it reads the yaml file at runtime.
custom:
myvar=true number# the command --custom myvar=1 yields the following porter.yaml
# myvar will be treated like a number by porter when it reads the yaml file at runtime.
custom:
myvar=1 Let's think for a sec about if it matters how the type is interpreted in the yaml anyway. The custom variable is always consumed by the bundle as a string:
If I'm wrong and it does matter, I think quotes can be forced by using tricks like number that I want to be a string# the command --custom myvar='"1"' yields the following porter.yaml
# myvar will be treated like a number by porter when it reads the yaml file at runtime.
custom:
myvar='"1"' Based on that, does this help answer your question and get rid of any type checking you had put in place? Or is there still more to figure out for that part? |
@carolynvs What I am thinking about was when we want to pipe the boolean/integer custom values (1) to properties that only accept boolean/integer values or (2) using it as the boolean/integer custom values, not string. The example that I am using is with docker as follows, using the whalesay bundle.
If I want to use the
While if we use double-quote, the
|
This error isn't because of a boolean. It's because the template syntax wasn't quoted (its not valid yaml).
should be
I really don't want you to go down a rabbit hole on the problems raised in #316. I am working on a fix for that by switching our template delimiters to work better with yaml but in the meantime don't try to solve "type problems" in this issue. If it ends up only working for string that's fine for now. |
Closed by #1900. |
I would like to be able to use the custom section as variables essentially. Here's one thing that I often want to do: tie a bundle directly to a version of an application. It's really hard to do without scripting out editing the dockerfile and porter.yaml so injecting like this where porter supports such a common case explicitly would make it much easier to package an app automatically when new versions are released.
This change should be made on the release/v1 branch.
The text was updated successfully, but these errors were encountered: