-
Notifications
You must be signed in to change notification settings - Fork 286
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
return codes not working #417
Comments
@kfox1111 Indeed there seems to be something wrong! Would you mind sharing the app you're building against? |
Basically the code from: buildpacks-community/kpack#237 but I had 'json' also in the requirements.txt file unnecessarily. it wasn't found and failed with a success. |
@kfox1111 What platform are you on? I just tried this locally and it failed. Maybe can you paste the whole output so we can get versions? Unlikely, but it an error in one of the components could be the cause.
± zm |develop ?:1 ✗| → cat app.py
from flask import Flask, Response
import os
import json
app = Flask(__name__)
@app.route('/')
def get_root():
js = json.dumps({'hello':'test'})
resp = Response(js, status=200, mimetype='application/json')
return resp
if __name__ == '__main__':
app.run() ± zm |develop ?:1 ✗| → cat requirements.txt
flask
gunicorn
json
|
centos7 Fulll run: |
Still unable to reproduce this issue. I've attempted to run 0.5.0 and 0.6.0 on Centos 8. Although I'm getting a network related issue it resorts to the same "exit status 103" message but the process exits as expected.
This is the current setup:
|
I had to reinstall my laptop as its ssd was warning it was going to fail soon. So I'm on centos 8 now. I can confirm it works as expected on centos 8. So something on centos 7 tickles it. |
I'm glad it's resolved for you. I went ahead and tested it on Centos 7 and sure enough I was able to reproduce the issue. It appears that it's related to an older version of docker available in the yum repo by default. After following the docker installation instructions for the latest docker-ce version the issue is resolved. I honestly didn't dig into any reported/resolved issues given that there are many versions in between (since 1.13.1 (2017-02-08)) but it's most likely related to an issue with the API we are using to await the execution of the container. It does bring up a question as to what versions of docker we support and whether we'd want hard restrictions to prevent elusive issues such as these. As for this issue, I will go ahead and close it. ReproductionResolution |
Ah, ok. That makes sense. I was using centos's docker rather then docker-ce. So I can confirm that. That brings up a new question though related to your support question. Redhat's not supporting docker at all anymore on el8. They prefer buildah. Its working pretty well here. It can even do unprivileged builds which is very nice. To do the test, I installed only the docker cli, and attached it to minikube to use its dockerd. I'm running a lot of docker-less Kubernetes clusters these days (containerd, cri-o). Under Kubernetes, I've had pretty good luck using Kaniko (https://github.com/GoogleContainerTools/kaniko) to produce images. It also can do unprivileged builds. So are there any plans for pack to support building without dockerd? |
@kfox1111 We are certainly looking into it. We used docker as a quick simple implementation. We haven't fully fleshed out exactly what it would entail but would look favorably at any contributions going in that direction. Here's a bit more info: |
Building an app that has an issue:
<snip>
The image clearly failed to build, but the shell result is 0 and text was "Successfully built image simple-app. This seems very wrong.
The text was updated successfully, but these errors were encountered: