Bug 1363956
Summary: | Fail to do sti build with no inputs in buildConfig | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Dongbo Yan <dyan> |
Component: | Build | Assignee: | Gabe Montero <gmontero> |
Status: | CLOSED ERRATA | QA Contact: | Wang Haoran <haowang> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3.3.0 | CC: | aos-bugs, bparees, gmontero, tdawson, vsemushi |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | No Doc Update | |
Doc Text: |
undefined
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2016-09-27 09:42:32 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Dongbo Yan
2016-08-04 06:54:42 UTC
The place to start appears to be this message from the actual build: E0804 01:33:52.199033 1 postexecutorstep.go:328] mv: cannot stat '/tmp/src/*': No such file or directory I've cc:ed Ben and Slava - any chance that the extended build stuff changed the starting point of where the code is located? I vaguely recall such a thing but am not certain. If it did, minimally the no src test cases didn't catch it, and those need to be bolstered. I'll try to reproduce in the short term. Refreshing my memory with this ... the Dockerfile for the no-src bldr image is: FROM openshift/ruby-20-centos7 RUN mkdir /tmp/src yes, I use sti build instead of docker build to build nosrc-bldr image. but it's the same issue with Dockerfile I'm seeing a different error than the one Dongbo Yan saw, but is the same one Slava saw today, which is something has undone the validation change to even allow a nosrc build: The BuildConfig "ruby-sample-build-nd" is invalid. spec.source: Invalid value: "": must provide a value for at least one source input(git, binary, dockerfile, images). Based on git blame, I suspect the change from Jimmi back in April for the Jenkinfile stuff: 1b81554b (Jimmi Dyson 2016-04-29 09:52:19 +0100 145) if s.DockerStrategy != nil && s.JenkinsPipelineStrategy == nil && spec.Source.Git == nil && spec.Source.Binary == nil && spec.Source.Dockerfile == nil && spec.Source.Images == nil { bc80045d (Ben Parees 2016-07-01 17:56:44 -0400 146) allErrs = append(allErrs, field.Invalid(fldPath.Child("source"), "", "must provide a value for at least one source input(git, binary, dockerfile, images).")) I'll see about working around this first, and then see if I see Dongbo Yan's error. Don't think it is line 145 ... something else must have change that altered the input into this method. I'll dig more on Friday. Ah, how my memory fails as I get older :-) .... nosrc is not allowed with docker strategy :-) ... remember now. Among other things, the validation unit tests confirm that. I see the same error on the source strategy config. I'll dig into it today. OK, I know what happened. The s2i ruby assemble script changed 24 days ago with commit https://github.com/sclorg/s2i-ruby-container/commit/1824d81af60eb25e843f79176340d3870cd31e00#diff-4a51d1cc3110008c2ba32a490e14ec72 where the cp was changed to a mv to save space. However, mv fails when trying to `mv /tmp/src/*` when there are no files there (the Dockerfile for our nosrc bldr image simply creates the /tmp/src dir currently). I think the cp to mv change is valid for real world apps. So the fix will be to update the Dockerfile in the QE's repo to also touch a file in /tmp/src in addition to the mkdir /tmp/src. Sending the bug back to QE so they can update their repo's Dockerfile accordingly, and try again. I confirmed that adding RUN touch /tmp/src/DUMMY.txt to the Docker file allows both the src and custom strategy bc's to build. yes, after updating Dockerfile, it works well. thanks openshift v3.3.0.14 kubernetes v1.3.0+57fb9ac etcd 2.3.0+git Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2016:1933 |