Exhaustive list of generalized Build API/CRD attributes

[sbose78]

The goal of the Build API is to be able to support:

• strongly typed 'popular' attributes that can be used to drive builds with different strategies.
• loosely typed not-so-popular name/value pairs in Build API's spec.parameters that would be used to express build steps in the BuildStrategy object definition.

As an exploration, we should enhance the Build API to have the common/popular strongly typed API attributes. Example,

• args
• runtime Image, path maps : tracked in Support creation of lean application "runtime" images #183
• ...
• Anything else you think we need to include?

Opening this issue to crowdsource suggestions on Build API enhancements.

[sbose78]

https://skaffold.dev/docs/references/yaml/
Even though the API objectives are different, the API sheds light on key attributes for popular strategies.

[zhangtbj]

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?

[sbose78]

By Build API , I mean the Build CRD.
And as per the project's promise, it's Kubernetes-native :)

[qu1queee]

@sbose78 thanks for the issue. Im trying to get this idea first, compared to how tekton tasks manage the spec.params see https://github.com/tektoncd/pipeline/blob/master/docs/tasks.md#specifying-parameters , how is it different to the spec.parameters that we want for the Build? Is there any overlap?

[sbose78]

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

[qu1queee]

@sbose78 I think I get the idea. Do we need to also layout specific PARAMs we know all strategies share?

[sbose78]

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.