Exhaustive list of generalized Build API/CRD attributes #184
Comments
|
https://skaffold.dev/docs/references/yaml/ |
|
Hi @sbose78 , I have a basic question. :) Where this Build API can be used? Will it just be used in OpenShift, or we can publish it for all kinds of kube platform? Access from the kube api? |
|
By Build API , I mean the Build CRD. |
sbose78
changed the title
|
@sbose78 thanks for the issue. Im trying to get this idea first, compared to how tekton tasks manage the |
|
It's kinda similar in idea, but in case of Build it's more of a loosely typed way to define parameterized values. Imagine a build strategy which needs user input which isn't part of a strongly typed attribute in the BUILD CRD. In that case, user could define it in params, and expect the build to pick it up and do the necessary replacement in the BuildStrategy for $(build.spec.params.something). I'll add an example to show it |
|
@sbose78 I think I get the idea. Do we need to also layout specific PARAMs we know all strategies share? |
|
If there are specific params which all build strategies share in a non-optional way, then that param should most likely be a strongly typed API attribute. |
This covers the use case introduced in issue shipwright-io#184 This also will provide an enhancement in the current Build API, by migrating existing fields into a more readable/understandable path.
This covers the use case introduced in issue shipwright-io#184 This also will provide an enhancement in the current Build API, by migrating existing fields into a more readable/understandable path.
This covers the use case introduced in issue shipwright-io#184 This also will provide an enhancement in the current Build API, by migrating existing fields into a more readable/understandable path.
This covers the use case introduced in issue shipwright-io#184 This also will provide an enhancement in the current Build API, by migrating existing fields into a more readable/understandable path.
This covers the use case introduced in issue shipwright-io#184 This also will provide an enhancement in the current Build API, by migrating existing fields into a more readable/understandable path.
This covers the use case introduced in issue shipwright-io#184 This also will provide an enhancement in the current Build API, by migrating existing fields into a more readable/understandable path.
This covers the use case introduced in issue shipwright-io#184 This also will provide an enhancement in the current Build API, by migrating existing fields into a more readable/understandable path.
This covers the use case introduced in issue shipwright-io#184 This also will provide an enhancement in the current Build API, by migrating existing fields into a more readable/understandable path.
This covers the use case introduced in issue shipwright-io#184 This also will provide an enhancement in the current Build API, by migrating existing fields into a more readable/understandable path.
This covers the use case introduced in issue shipwright-io#184 This also will provide an enhancement in the current Build API, by migrating existing fields into a more readable/understandable path.
This covers the use case introduced in issue shipwright-io#184 This also will provide an enhancement in the current Build API, by migrating existing fields into a more readable/understandable path.
This covers the use case introduced in issue shipwright-io#184 This also will provide an enhancement in the current Build API, by migrating existing fields into a more readable/understandable path.
The goal of the Build API is to be able to support:
spec.parametersthat would be used to express build steps in theBuildStrategyobject definition.As an exploration, we should enhance the Build API to have the common/popular strongly typed API attributes. Example,
argsruntimeImage, path maps : tracked in Support creation of lean application "runtime" images #183Opening this issue to crowdsource suggestions on Build API enhancements.
The text was updated successfully, but these errors were encountered: