-
Notifications
You must be signed in to change notification settings - Fork 113
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
Conversation
I only tested on Kube |
No worries @HeavyWombat, that looked like the typical hanging BuildAh build. |
There was a problem hiding this 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.
There was a problem hiding this 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.
424731d
to
7d1cf1d
Compare
There was a problem hiding this 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"` |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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).
7d1cf1d
to
1eaa049
Compare
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. |
1eaa049
to
38139a0
Compare
@HeavyWombat pls see the comment on squashing
|
@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? |
0277f2a
to
0523d53
Compare
There was a problem hiding this 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!!
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. |
There was a problem hiding this 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).
| 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. | |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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{} |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
c0b0f93
to
7aa3e37
Compare
f0462e8
to
36dbd56
Compare
36dbd56
to
b1ca5f2
Compare
/unhold |
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.
b1ca5f2
to
ac18f62
Compare
Had a bit of a rebase hick-up of sorts. Should be fixed now. |
Seeing all comments from Adam addressed, re-adding /lgtm |
/lgtm |
Changes
Fixes #677
Based upon SHIP #29
Core SHIP proposals:
BuildSpec
inBuildRun
Build
registered in the cluster.BuildRef
,output
,paramValues
,env
, ortimeout
.Submitter Checklist
See the contributor guide
for details on coding conventions, github and prow interactions, and the code review process.
Release Notes