-
Notifications
You must be signed in to change notification settings - Fork 698
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
s2i build --as-dockerfile not using local .s2i/[assemble, run] when builder image present #1124
Comments
looks like a long standing bug in source-to-image/pkg/build/strategies/dockerfile/dockerfile.go Lines 130 to 134 in 980ca19
since the image itself as a label that indicates it provides scripts, "hasAllScripts" ends up true and so we never scan the local repository for override scripts. the logic looks almost deliberate, which is interesting but i'm pretty sure the behavior is incorrect. Looks like it went in here: 6815fa6 I reviewed/approved it but i think we missed this scenario when thinking about it. |
I have the same problem. As a workaround, I perform a "replacement" in the generated dockerfile. |
Resolves #1124: Always scan the repository for provided scripts
I see that the last release does not include those fixes -- v1;3.9 from Oct 19th, while PR got merged after Any ETA for next release? |
... oh... nevermind ... |
When running s2i build with both local script files and a valid builder image, I'm not seeing the resulting
dockerfile having the correct RUN and CMD statements. However, when pointing to an invalid builder image
the expected set of statements and other elements (in the debug log) appear present in the container build file.
Version: 1.3.2 (Fedora 38) and 1.3.8
Reproduction:
(This repository contains both .s2i/bin/run and .s2i/bin/assemble
$ cat Containerfile.invalid
I would expect the RUN and CMD to point to the local files, not the originals for the builder image.
Using a nonexistant builder image (with the same repository) yields what I believe is the correct results.
$ s2i build . registry.access.redhat.com/ubi8/php-83 --as-dockerfile Containerfile.valid --loglevel=5
$ cat Containerfile.valid
I'm not sure if I'm invoking this right or if I'm missing some other key attribute or behavior here.
The text was updated successfully, but these errors were encountered: