Skip to content
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

Params EP Implementation #781

Conversation

qu1queee
Copy link
Contributor

@qu1queee qu1queee commented May 17, 2021

Changes

Implements the parameterize-strategies EP

Note: I modified the API, as spec.params in all CRD´s might be confusing I decided to use:

  • spec.params for Build and BuildRuns
  • spec.parameters for Strategies.

I would open another PR after this one gets merged, to introduce a tutorial on how to build a strategy with parameters.

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 support for parameters in the strategies, so that users can parameterize their usage.

@qu1queee qu1queee added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label May 17, 2021
@openshift-ci openshift-ci bot added the release-note Label for when a PR has specified a release note label May 17, 2021
@openshift-ci openshift-ci bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label May 19, 2021
@qu1queee qu1queee force-pushed the qu1queee/ep_params_implementation branch from 4c01830 to 1928515 Compare May 23, 2021 19:46
@openshift-ci openshift-ci bot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label May 23, 2021
@qu1queee qu1queee force-pushed the qu1queee/ep_params_implementation branch 10 times, most recently from 15bdb71 to 7852d9f Compare May 30, 2021 19:07
@qu1queee qu1queee force-pushed the qu1queee/ep_params_implementation branch 4 times, most recently from 410baa6 to eb8209c Compare May 31, 2021 08:04
@qu1queee qu1queee removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label May 31, 2021
@qu1queee qu1queee changed the title WIP: Params EP Implementation Params EP Implementation May 31, 2021
@qu1queee qu1queee requested review from HeavyWombat, imjasonh and SaschaSchwarze0 and removed request for HeavyWombat May 31, 2021 08:10
@qu1queee qu1queee force-pushed the qu1queee/ep_params_implementation branch 3 times, most recently from d509e90 to 4e696a3 Compare June 14, 2021 14:17
@qu1queee qu1queee force-pushed the qu1queee/ep_params_implementation branch from 4e696a3 to 2294c13 Compare June 14, 2021 15:00
Copy link
Member

@SaschaSchwarze0 SaschaSchwarze0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work. I have so many use cases in mind to leverage that. :-)

Based on our usual agreement, as it contains API changes, requires a second review. @imjasonh having some minutes?

/approve
/assign imjasonh

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jun 14, 2021

[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:

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

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 14, 2021
Copy link
Contributor

@imjasonh imjasonh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly lgtm, some small readability comments but otherwise nothing structural.

Thanks for this PR, and sorry it took so long for me to review it.

pkg/reconciler/buildrun/resources/params_test.go Outdated Show resolved Hide resolved
}

// override params that matches by name in both originalParams and overrideParams
for i, o := range originalParams {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be a bit more readable and performant to first convert both lists into map[string]Param, then you can do lookups without having to double-loop.

I don't think in practice the performance will be noticeable, but I get nervous any time I see nested fors.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, good idea, done.

pkg/reconciler/buildrun/resources/params_test.go Outdated Show resolved Hide resolved
pkg/reconciler/buildrun/resources/params_test.go Outdated Show resolved Hide resolved
@@ -37,6 +38,10 @@ const (
inputParamContextDir = "CONTEXT_DIR"
)

var (
systemReservedParametersRegexp = regexp.MustCompile("BUILDER_IMAGE|DOCKERFILE|CONTEXT_DIR|(shp-.*)")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this instead be expressed as a helper function that checks if the string is in a set of disallowed strings, and doesn't have the shp- prefix?

I find that regular expressions can be hard to read and understand, which can lead to bugs. If it can be implemented in reasonably brief code that's usually better in my experience:

var reserved := map[string]bool{
  "BUILDER_IMAGE": true,
  "DOCKERFILE":    true,
  "CONTEXT_DIR":   true,
}
func isReserved(n string) bool {
  return reserved[n] || strings.HasPrefix("shp-")
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, nice, done.

pkg/validate/strategies.go Outdated Show resolved Hide resolved
pkg/validate/strategies.go Outdated Show resolved Hide resolved
@qu1queee qu1queee force-pushed the qu1queee/ep_params_implementation branch 2 times, most recently from 5b46715 to f014205 Compare June 22, 2021 18:48
@qu1queee qu1queee requested a review from imjasonh June 22, 2021 18:51
Copy link
Contributor Author

@qu1queee qu1queee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@imjasonh added all your request for changes, thanks

@qu1queee qu1queee force-pushed the qu1queee/ep_params_implementation branch 2 times, most recently from 90956bf to a1e0909 Compare June 23, 2021 10:21
type Parameter struct {
// Param is a key/value that populates a strategy parameter
// used in the execution of the strategy steps
type Param struct {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do you feel about ParamValue, a field named paramValues:, etc.? It's a bit confusing to have both Parameter and Param types (Tekton has this issue as well)

Copy link
Contributor Author

@qu1queee qu1queee Jun 24, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not my favorite field name tbh, but I see the benefit. The concern I have now, is that these naming conventions were already accepted via the related EP before, by different people.

My options on this:

  • Block this till consensus from more folks, as the change params->paramValues is high.
  • Merge this, and then look for consensus. If we need to change this, then we PR the change.

What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@imjasonh I did the changes as requested. FYI I sync on this offline with @SaschaSchwarze0 and @HeavyWombat , we all agree its a good alternative. Please re-review this PR again.

pkg/validate/strategies.go Outdated Show resolved Hide resolved
@qu1queee qu1queee force-pushed the qu1queee/ep_params_implementation branch from a1e0909 to 3a9cdf1 Compare June 24, 2021 14:35
@qu1queee qu1queee requested a review from imjasonh June 24, 2021 14:44
Extend Build and BuildRun to support spec.params
Extend the Strategies to support spec.parameters
Regenerate CRD´s files
Support test cases for using params. Apply this to both
namespaced and cluster-scope strategies.
Ensure that on TaskRun creation we can add the strategy parameters
as part of the Task parameters, and that we populate their values
via the Build/BuildRun params definition.
Validate that a param is:
- not colliding with system parameters
- exists in the strategy parameters
- overrides via a BuildRun can happen, as long as the param exists in
  the Build

Also extend Build custom errors, to support two new ones:
- RestrictedParametersInUse
- UndefinedParameter
- Extend Build docs
- Extend BuildRun docs
- Extend Strategy docs
- Update parameterize EP and set to `implemented`.
Make a clear distinction on calling the Build/BuildRun params as
`spec.paramValues` instead of `spec.params`
@qu1queee qu1queee force-pushed the qu1queee/ep_params_implementation branch from 3a9cdf1 to 1970780 Compare June 25, 2021 10:33
Copy link
Contributor

@imjasonh imjasonh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

Thanks!

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Jun 25, 2021
@openshift-merge-robot openshift-merge-robot merged commit 43ed730 into shipwright-io:main Jun 25, 2021
@qu1queee qu1queee deleted the qu1queee/ep_params_implementation branch June 25, 2021 11:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API kind/feature Categorizes issue or PR as related to a new feature. lgtm Indicates that a PR is ready to be merged. release-note Label for when a PR has specified a release note
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants