Bug 1696756
Summary: | Source strategy builds using wrong Assemble User | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Adam Kaplan <adam.kaplan> |
Component: | Build | Assignee: | Adam Kaplan <adam.kaplan> |
Status: | CLOSED ERRATA | QA Contact: | wewang <wewang> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 4.1.0 | CC: | aos-bugs, gdumplet, jmorales, wzheng |
Target Milestone: | --- | ||
Target Release: | 4.1.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | No Doc Update | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-06-04 10:47:08 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
Adam Kaplan
2019-04-05 14:58:15 UTC
@Graham (original reporter - CC-ed) - the "different Dockerfile" you are seeing is the new output from S2I builds. In 4.1 Source strategy builds generate a fixed Dockerfile that buildah consumes. I think the bug here is that we're hard-coding the assemble user to "1001" if the image doesn't have the "io.openshift.s2i.assemble-user" label, but we are not checking the "last" user in the base builder image. It can't be because of your S2I build behaviour, as this isn't an S2I build, it is a "docker" type build and it should be doing what my Dockerfile tells it to. The Dockerfile just happens to be invoking the "assemble" script after faking up the image to mirror what S2I would do. I cannot see therefore how they are related. If it is for some reason apply S2I builds steps for a "docker" build, it is even more confused. Haha, I should check my own build configuration. It is setup for "source" build, when it wasn't intended to. Since I fake out the Dockerfile to trigger an S2I build so can build on quay.io, I can just switch to "docker" build to get around the problem. Thanks. @Adam Kaplan @Graham Dumpleton I tested it in version: 4.0.0-0.11, builds completes, it works,custom keycloak image use the correct dockerfile with USER 1000 steps: 1. oc new-app https://raw.githubusercontent.com/openshift-labs/workshop-spawner/develop/templates/jumpbox-server-development.json 2. Check build and the logs of jumpbox-keycloak $ oc get builds NAME TYPE FROM STATUS STARTED DURATION jumpbox-hub-1 Docker Git@c7b2418 Complete 3 minutes ago 2m3s jumpbox-keycloak-1 Docker Git@c7b2418 Complete 3 minutes ago 2m5s $ oc logs -f build/jumpbox-keycloak-1 http://pastebin.test.redhat.com/750619 3.Get bc of jumpbox-keycloak source: contextDir: keycloak git: ref: develop uri: https://github.com/openshift-labs/workshop-spawner.git type: Git strategy: dockerStrategy: ###docker strategy from: kind: DockerImage name: jboss/keycloak-openshift:4.0.0.Final type: Docker If you use: oc new-app https://raw.githubusercontent.com/openshift-labs/workshop-spawner/develop/templates/jumpbox-server-development.json just then, it will work because the build configuration was switched to a docker build instead of source build. Instead use: oc new-app https://raw.githubusercontent.com/openshift-labs/workshop-spawner/3.0.4/templates/jumpbox-server-development.json if you are trying to replicate it. That is use version 3.0.4, which has setup for source build. There was confusion on my part initially because I thought it was using a docker build, when it was actually using a source build. Builder PR: https://github.com/openshift/builder/pull/61 Additional test cases needed in origin, but this is ready for QE. Verified in 4.0.0-0.ci-2019-04-11-185255 payload: registry.svc.ci.openshift.org/ocp/release@sha256:fdeeee0c19bd7b5873744dacf5859ac8adf0850961b7a449db839068f5ce7aef 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-2019:0758 |