-
Notifications
You must be signed in to change notification settings - Fork 284
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
Image has no entry point #52
Comments
Yeah, this definitely seems to be a regression. We'd talked about removing the defaulting of |
Are you using a base image that sets |
@sclevine I thought the entrypoint should always be the @dsyer setting entrypoint on your stack run image should fix the issue. |
@ekcasey We're both half-right. The current stacks set the I opened an issue against the spec here: buildpacks/spec#15 |
Do I know what the run image is? UPDATE: Found it in |
Update from WG meeting on 2018-10-16: We decided that the exporter should be responsible for adding the launcher to the run image and setting the This is important to guarantee that the builder and launcher lifecycle components are always compatible for a given image. Will follow up with a PR for buildpacks/spec#15. |
The |
@sclevine This work correctly on master of lifecycle but I believe we need to release new |
@sclevine I wrote a simple Python Tornado application. When I tried running the image that the buildpack created I got the following error:
The entrypoint is set to:
If I run:
then it works. Is this expected? |
This is the expected behavior when the buildpack doesn’t set a start command. What buildpack are you using? Python doesn’t have a widely adopted convention for an entry file, so Python buildpacks often don’t set a default command. |
Is there a way to tell whether the buildpack sets a start command? I see that a Dockerfile is not generated when you do a build. I'm using the Heroku buildpacks. I think it selected 18 if that makes sense. |
It’s the buildpack’s responsibility to warn you. @hone works at Heroku and might be able to direct your question to the right folks. As a workaround, you could use (We generate OCI images without using Dockerfiles at all. This lets us reuse arbitrary layers from previous builds and avoid downloading layers that only need to be reused at runtime. It also means we can build reproducible images in unprivileged containers.) |
This used to work. Not sure what changed, but I don't think it was anything I did.
The image is fine apart from the entry point, so I can run it if I provide on manually, i.e.
docker run dsyer/app /lifecycle/launcher web
.The text was updated successfully, but these errors were encountered: