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

Support BuildSpec in BuildRun resources #1016

Merged
merged 1 commit into from
Apr 4, 2022

Conversation

HeavyWombat
Copy link
Contributor

@HeavyWombat HeavyWombat commented Mar 20, 2022

Changes

Fixes #677

Based upon SHIP #29

Core SHIP proposals:

  • Have BuildSpec in BuildRun
  • Embedded build spec does not lead to Build registered in the cluster.
  • Validation steps are done against embedded Build(Spec).
  • The embedded build spec, does not count as a Build in the context of the metrics package.
  • No TaskRun is created when Build(Spec) is invalid
  • BuildSpec is not used in combination with BuildRef, output, paramValues, env, or timeout.
  • README is updated with embedded example instead of Build and BuildRun example

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

See the contributor guide
for details on coding conventions, github and prow interactions, and the code review process.

Release Notes

Introducing support to embed a BuildSpec inside a BuildRun to have one-off builds, where only a BuildRun is required without the need of a Build resource. This includes an API change as the BuildRef in BuildRuns is no longer mandatory. Either BuildRef or BuildSpec can be used.

@HeavyWombat HeavyWombat added the kind/feature Categorizes issue or PR as related to a new feature. label Mar 20, 2022
@openshift-ci openshift-ci bot added the release-note Label for when a PR has specified a release note label Mar 20, 2022
@openshift-ci openshift-ci bot requested review from gabemontero and sbose78 March 20, 2022 22:30
@HeavyWombat
Copy link
Contributor Author

I only tested on Kube 1.21 so far, the E2E tests are failing in a 1.20 setup. Have to have a look at this.

@SaschaSchwarze0
Copy link
Member

I only tested on Kube 1.21 so far, the E2E tests are failing in a 1.20 setup. Have to have a look at this.

No worries @HeavyWombat, that looked like the typical hanging BuildAh build.

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. The pragmatic way of using an inline build has advantages and disadvantages. Without encouraging you to go away from it, there is one thing which imo should not happen: at certain places, we store a Build name: as a label on the BuildRun or TaskRun. And as label in Prometheus metrics. I don't think we should store a fake value there.

Imo BuildRun and TaskRun labels should not be set at all. In Prometheus, we must provide a value for the build label, but maybe "" is a better choice.

README.md Outdated Show resolved Hide resolved
docs/buildrun.md Outdated Show resolved Hide resolved
docs/buildrun.md Outdated Show resolved Hide resolved
pkg/apis/build/v1alpha1/buildrun_types.go Outdated Show resolved Hide resolved
pkg/reconciler/buildrun/buildrun.go Outdated Show resolved Hide resolved
pkg/reconciler/buildrun/resources/build.go Outdated Show resolved Hide resolved
pkg/reconciler/buildrun/buildrun.go Outdated Show resolved Hide resolved
pkg/reconciler/buildrun/resources/sources/http.go Outdated Show resolved Hide resolved
pkg/validate/validate.go Outdated Show resolved Hide resolved
Copy link
Member

@dalbar dalbar left a comment

Choose a reason for hiding this comment

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

Great work @HeavyWombat especially on the validation and tests. I have some minor change requests.

pkg/validate/validate.go Show resolved Hide resolved
pkg/reconciler/buildrun/buildrun.go Outdated Show resolved Hide resolved
pkg/reconciler/buildrun/resources/build.go Outdated Show resolved Hide resolved
pkg/apis/build/v1alpha1/buildrun_types.go Outdated Show resolved Hide resolved
@HeavyWombat HeavyWombat force-pushed the add/one-off-builds branch 2 times, most recently from 424731d to 7d1cf1d Compare March 22, 2022 13:56
Copy link
Contributor

@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.

Thanks this is nice. From my review I see the following:

[1] Introducing too many changes not related to this feature. Some of them are nice fixes, the rest I do not understand the rational, but they can go in. I'm just concerned that your code style is not gonna get widely adopted, so we will see what you change today again the future(take the imports as an example), not sure how much of value it have then. With this in mind, pls squash the following commits into one:

  • Fix potentially unused variable warning
  • Sort imports in build_test.go
  • Use specific description for bundle test
  • Add convenience checks for test env vars
  • Fix duplicate import
  • Refactor to fix potential variable shadow issue
  • Fix build not found test case
  • Clean-up Makefile
  • Fix declaration of "err" shadows declaration issue
  • Simplify if error case
  • Add/remove empty lines in buildrun_test.go

[2] I wrote a comment on this pr reintroducing a pointer. I was not involved on the discussion but we have that pointer before and then we went through a long discussion and that was removed. Wondering if you are aware of this.

BuildRef BuildRef `json:"buildRef"`
//
// +optional
BuildRef *BuildRef `json:"buildRef"`
Copy link
Contributor

Choose a reason for hiding this comment

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

this is a regression of what was done recently in #397 , can u take a look?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, this is fine. With the introduction of BuildSpec, the BuildRef needs to be optional now. Otherwise we could have both a build reference and an embedded build(spec).

@HeavyWombat
Copy link
Contributor Author

Thanks this is nice. From my review I see the following:

[1] Introducing too many changes not related to this feature. Some of them are nice fixes, the rest I do not understand the rational, but they can go in. I'm just concerned that your code style is not gonna get widely adopted, so we will see what you change today again the future(take the imports as an example), not sure how much of value it have then. With this in mind, pls squash the following commits into one:

* Fix potentially unused variable warning

* Sort imports in build_test.go

* Use specific description for bundle test

* Add convenience checks for test env vars

* Fix duplicate import

* Refactor to fix potential variable shadow issue

* Fix build not found test case

* Clean-up Makefile

* Fix declaration of "err" shadows declaration issue

* Simplify if error case

* Add/remove empty lines in buildrun_test.go

[2] I wrote a comment on this pr reintroducing a pointer. I was not involved on the discussion but we have that pointer before and then we went through a long discussion and that was removed. Wondering if you are aware of this.

This work resulted in a number of related side changes. They added up over time to be honest. These were only done in files that I had to touch anyway. For consistency, I updated the same for example linter issue in the same file, too. Where possible, I opted to create a spin-off PR and moved the commit into it, i.e. #1018 and #1019.

With regards to the sorting order of imports, @gabemontero please keep me honest, I think we spoke about this in an earlier PR. The idea would be to have the Kubeish imports separately. I kind of like the idea, helps with getting a quick overview. However, we have no automated way to "enforce" the order. Some files have it, some do not. In come cases, other PRs updated the imports to have them sorted. If there is some easy and automated way to have that, we maybe should follow-up on that.

@qu1queee
Copy link
Contributor

@HeavyWombat pls see the comment on squashing

pls squash the following commits into one

@HeavyWombat
Copy link
Contributor Author

@HeavyWombat pls see the comment on squashing

pls squash the following commits into one

@qu1queee I fail to see the rational behind this to be honest. To squash them into one commit, I have to come up with a generic subject line for all of the combined changes. This will be very generic description. If I for example use GitLens, rather than a very specific subject, I only see the generic "fixing things" subject. Care to share your thoughts behind the squashing?

@HeavyWombat HeavyWombat force-pushed the add/one-off-builds branch 3 times, most recently from 0277f2a to 0523d53 Compare March 23, 2022 09:36
Copy link
Contributor

@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.

All good from my side, this is good stuff!!

@gabemontero
Copy link
Member

Similar as in the other one, given this includes an API change, we'll need a second review. @adambkaplan @gabemontero

I'm good with API ... very similar pattern as to seen in k8s and tekton

I'll

/lgtm

but will

/hold

in case @adambkaplan gets time to take a look and chime in. If he doesn't by EOB Friday Apr 1, go ahead and unhold.

@openshift-ci openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Mar 31, 2022
@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Mar 31, 2022
Copy link
Member

@adambkaplan adambkaplan left a comment

Choose a reason for hiding this comment

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

Generally looks good, I request that you squash commits before merging (all code changes can be bundled together).

docs/buildrun.md Show resolved Hide resolved
docs/buildrun.md Outdated Show resolved Hide resolved
Comment on lines +303 to +305
| False | BuildRunNoRefOrSpec | Yes | BuildRun does not have either `BuildRef` or `BuildSpec` defined. There is no connection to a Build specification. |
| False | BuildRunAmbiguousBuild | Yes | The defined `BuildRun` uses both `BuildRef` and `BuildSpec`. Only one of them is allowed at the same time.|
| False | BuildRunBuildFieldOverrideForbidden | Yes | The defined `BuildRun` uses an override (e.g. `timeout`, `paramValues`, `output`, or `env`) in combination with `BuildSpec`, which is not allowed. Use the `BuildSpec` to directly specify the respective value. |
Copy link
Member

Choose a reason for hiding this comment

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

Noteworthy that this is a good use case for a validating admission webhook (which we have previously discussed in #596)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, exactly, I dropped a comment with that in the code at the respective place.

if buildRun.Spec.BuildSpec != nil {
build.Name = ""
build.Namespace = buildRun.Namespace
build.Spec = *buildRun.Spec.BuildSpec
Copy link
Member

Choose a reason for hiding this comment

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

Perhaps a nit (I won't block this from merging). There's a bug risk here if somewhere downstream buildRun.Spec.BuildSpec is mutated. I would prefer a deep copy was used here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added a deepcopy instead. Thanks for the hint.

build.Name = ""
build.Namespace = buildRun.Namespace
build.Spec = *buildRun.Spec.BuildSpec
build.Status = buildv1alpha1.BuildStatus{}
Copy link
Member

Choose a reason for hiding this comment

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

Doesn't the Build object normally require certain status fields to be set in order for it to be used in a BuildRun? If so, it would make sense to set these here.

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, this is done in the reconciler code.

@openshift-ci openshift-ci bot added needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. and removed lgtm Indicates that a PR is ready to be merged. needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. labels Apr 1, 2022
@openshift-ci openshift-ci bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Apr 1, 2022
@openshift-ci openshift-ci bot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Apr 1, 2022
@gabemontero
Copy link
Member

/unhold

@openshift-ci openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Apr 1, 2022
Make `BuildRef` optional and generate CRDs and fix all occurrences.

Introduce code in `GetBuildObject` to support both the `BuildRef` approach and
the new `BuildSpec` option. Return a transient in-memory Build resource in case
the BuildRun has an embedded BuildSpec.

Add optional `BuildSpec` in BuildRun spec.

Add E2E test cases for embedded builds in buildruns.

Add new BuildRun validation option in docs.

Remove variable name for `context` to make it undefined (linter warning).

Add empty lines for readability.

Sort imports based on common kube/others order.

Replace copy/paste description with specific one for bundle tests.

Add `Expect`s to give human readable error in case test environment variables
are not set.

Remove duplicate import of `k8s.io/api/core/v1`.

Simplify code by removing the `if` check.

Fix warning that variable declaration could shadow previous variable value by
refactoring the respective `if` block.

Add or remove empty lines in `buildrun_test.go` to increase readability and to
keep the same style as in other test cases.

Refactor code to fix variable value shadow warning.

Replace generic `errors.New("not found")` with Kube specific one.

Introduce empty status call stub (not not fail in status update case).

Refactor return statement to be more simple.

Introduce `BuildSpec` in BuildRun spec

Refactor build reconciler logic by inlining `UpdateBuildStatusAndRetreat`
function that is only used once.

Add test case to cover special case for build resource not being in the system.

Refactor validation code by moving out validation list into a global variable.

Add convenience function to get the name of the referenced build.

Use `resources.GetBuildObject` instead of manual look-up in test cases.

Introduce controller-runtime Kubernetes client in test handle.

Add functions to create the validation structs in a consistent way.

Add convenience function to validate a Build with validation varargs.

Introduce validation code for field permutations.

Add test cases for field validation.

Fix markdown linter warnings and indention.
@HeavyWombat
Copy link
Contributor Author

Had a bit of a rebase hick-up of sorts. Should be fixed now.

@SaschaSchwarze0
Copy link
Member

Seeing all comments from Adam addressed, re-adding lgtm

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Apr 4, 2022
@qu1queee
Copy link
Contributor

qu1queee commented Apr 4, 2022

/lgtm

@openshift-merge-robot openshift-merge-robot merged commit 5b03a5c into main Apr 4, 2022
@qu1queee qu1queee deleted the add/one-off-builds branch April 4, 2022 09:43
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.

As a shipwright developer, I want to ensure BuildRuns can support the Build Spec
7 participants