Add EP on Build Strategies Parametrization

[qu1queee]

Changes

Provides an EP on how to manage parameters in Strategies, by providing more flexibility to Shipwright users and strategy administrators.

Submitter Checklist

• Includes tests if functionality changed/was added
• Includes docs if changes are user-facing
• Set a kind label on this PR
• Release notes block has been filled in, or marked NONE

Release Notes

Add EP on Parameterize Build Strategies

[SaschaSchwarze0]

Nice. Bringing some suggestions and aspects for discussion.

[adambkaplan]

@qu1queee do we need to reach a decision in #694 to make progress on this EP, or is this a related issue that you uncovered drafting the issue?

[gabemontero]

Quick FYI, I've been asked to take a look at #224 and compose an EP for that.

Now, while #224 gets into treating env vars as a "first class citizen" in the api, vs. just a subset of parameters, my thought is that this EP can still be a building block or prereq for an EP written for env vars in that we would want to look at supporting parameterization/perform variable substitution/provide defaults for env vars like what is available for Tekton.

In my initial planning for the EP, I'm thinking I'm going to call this one out as a "dependency" in some fashion, even though separate APIs will arise to satisfy the "first class treatment" @sbose78 called for.

Anyway, I'm not saying this EP should reference "env var scenarios" specifically. Just wanted to mention here what has been alluded to in other issues, etc. as well as I think the community call, in that there is "a connection". Certainly the motivations @qu1queee mentioned up top in this EP lend themselves minimally to what Tekton does with env vars today, at least IMO.

And of course opinions on this dependency notion, connection, etc. are welcome.

That said, if you want @qu1queee to call out the "env var scenario" in some fashion here I certainly won't object.

Some quick references I'm sure the folks already commenting here are aware of:

• https://github.com/tektoncd/pipeline/blob/main/docs/variables.md#fields-that-accept-variable-substitutions

Just refreshed my memory with the tekton code: the tekton pipline taskrun reconciler performs variable substitution on the taskrun.taskspec.step/container.envvar fields; As shipwright generates a task run with a task spec, would can leverage tekton's support here. Will include this in my upcoming ep.

• https://github.com/tektoncd/pipeline/blob/main/docs/tasks.md#specifying-a-step-template

Just refreshed my memory with the tekton code: step templates are part of the task spec which is what shipwright manipulates when building a task run. So, the defaulting notion provided by step templates also seems to be something we can exploit. Shipwright's task spec generation is not generating a spec template yet, but I see no reason in the current code why it could not.

• https://github.com/tektoncd/pipeline/blob/main/docs/tasks.md#using-a-secret-as-an-environment-source

(you see a direct use of params to seed the k8s valueFrom there)

[qu1queee]

@adambkaplan this EP assumes the decision is to expose the Tekton nomenclature.

[qu1queee]

@gabemontero thanks, nice summary. I think we can keep this EP without a notion of env vars, but I definitely see this the other way around, where env vars EP should reference this one, mainly because of the variable substitution, where a var comes for a parameter definition.

[SaschaSchwarze0]

/approve

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: SaschaSchwarze0

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [SaschaSchwarze0]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[imjasonh]

/lgtm

[gabemontero]

@gabemontero thanks, nice summary. I think we can keep this EP without a notion of env vars, but I definitely see this the other way around, where env vars EP should reference this one, mainly because of the variable substitution, where a var comes for a parameter definition.

sounds good @qu1queee

and my EP draft #726 in fact does reference this one

thanks