-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
move builder images to use external apis #17699
move builder images to use external apis #17699
Conversation
39caa0f
to
628cbdf
Compare
@@ -215,14 +215,14 @@ func main() { | |||
|
|||
// make sure that all the allowed imports are used | |||
if unused := unusedPackageImports(restriction.AllowedImportPackages, packages); len(unused) > 0 { | |||
log.Printf("-- found unused package imports\n") | |||
log.Printf("-- found unused allowed package imports(remove them)\n") |
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.
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.
heh. Sure.
bc90009
to
b7f7e4f
Compare
/retest |
@openshift/sig-developer-experience @deads2k ptal. Note that I will be relocating the new/duplicated constants from their present "utils" location into the external api types file once the dust settles from the rebase. |
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.
lgtm
One question: I saw the verify test passed ... just curious about the need for make update
type changes; were they done previously, when the new api packages were first introduced, and simply referencing them here in pkg/build is orthogonal?
any time you pull external api changes into origin you need to run make update as part of your PR because the conversion code (between the external types and internal types) lives in origin and must be updated. |
b7f7e4f
to
74d424d
Compare
74d424d
to
af88e7f
Compare
af88e7f
to
b7bada8
Compare
40b5759
to
7e64054
Compare
obj, groupVersionKind, err := legacyscheme.Codecs.UniversalDecoder().Decode([]byte(buildStr), nil, nil) | ||
cfg.build = &buildapiv1.Build{} | ||
|
||
obj, groupVersionKind, err := legacyscheme.Codecs.UniversalDecoder().Decode([]byte(buildStr), nil, cfg.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.
The legacy scheme keeps you pinned to the internal versions to operate. You'll need a follow up to remove the dependency. Definitely not a blocker.
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.
is there a different decoder/scheme I should be using instead?
@@ -73,11 +71,8 @@ func newBuilderConfigFromEnvironment(out io.Writer, needsDocker bool) (*builderC | |||
} | |||
glog.V(4).Infof("redacted build: %v", string(bytes)) | |||
} | |||
if errs := validation.ValidateBuild(cfg.build); len(errs) > 0 { |
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.
Interesting. What did you want this protection for?
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.
I think it was belt+suspenders. It sort of confirmed that the build object we serialized into the env variable was in fact still valid when we deserialized it on the other side. The build object would have already been through validation when it was created in the first place. Given how impossible it would have been to retain this check(since validation runs against internal apis), I opted for removing the additional protection.
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.
I think it was belt+suspenders. It sort of confirmed that the build object we serialized into the env variable was in fact still valid when we deserialized it on the other side. The build object would have already been through validation when it was created in the first place. Given how impossible it would have been to retain this check(since validation runs against internal apis), I opted for removing the additional protection.
Ok. In general, client-side validation on something like this is questionable since the client rules are unlikely to consistently match the server rules.
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.
right, well prior to splitting things out it was using the same rules(same code). but now it's being removed so it's moot.
stages := fromContext(ctx) | ||
return *stages | ||
} | ||
|
||
// RecordStageAndStepInfo records details about each build stage and step | ||
func RecordStageAndStepInfo(stages []buildapiv1.StageInfo, stageName buildapiv1.StageName, stepName buildapiv1.StepName, startTime metav1.Time, endTime metav1.Time) []buildapiv1.StageInfo { |
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.
Straight move?
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.
other than changing it to use external api objects, yeah.
|
||
// OriginVersion is an environment variable key that indicates the version of origin that | ||
// created this build definition. | ||
OriginVersion = "ORIGIN_VERSION" |
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.
Are these guaranteed in any way for custom builds?
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.
sort of? we document it here:
https://docs.openshift.org/latest/creating_images/custom.html#custom-builder-image
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.
sort of? we document it here:
https://docs.openshift.org/latest/creating_images/custom.html#custom-builder-image
That makes it sound a lot like an API constant. Doesn't need to move here, but if it is guaranteed, we can't change it, and we expect clients to consume it, then it is a good target for moving to openshift/api.
Very minor comments, nothing that would keep me from merging this as-is (minus the bump thing). lgtm |
/retest |
7e64054
to
3ce3e8a
Compare
/retest |
3ce3e8a
to
05adf6e
Compare
05adf6e
to
66c9d91
Compare
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bparees The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
/retest |
/retest |
/retest Please review the full test history for this PR and help us cut down flakes. |
/test all [submit-queue is verifying that this PR is safe to merge] |
@bparees: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
Automatic merge from submit-queue (batch tested with PRs 17699, 17820). |
No description provided.