Tekton build fails with "failed to export: determining entrypoint: tried to set web to default but it doesn't exist"

[manong-detective]

If you use the buildpack task in tekton to specify heroku/builder:22 to build a python project, you'll run into problems finding the entry. But using gcr.io/buildpacks/builder: v1 and paketobuildpacks/builder: base is ok, don't know is what reason, specific error message as below

===> ANALYZING Image with name "us-central1-docker.pkg.dev/infrastructure-410808/nebula/python-demo:v1.1.5" not found ===> DETECTING 1 of 2 buildpacks participating heroku/python 0.8.4 ===> RESTORING Restoring metadata for "heroku/python:pip-cache" from cache Restoring data for "heroku/python:pip-cache" from cache ===> BUILDING [Determining Python version] No Python version specified, using the current default of Python 3.12.3. To use a different version, see: https://devcenter.heroku.com/articles/python-runtimes [Installing Python and packaging tools] Installing Python 3.12.3 Installing pip 24.0, setuptools 68.0.0 and wheel 0.42.0 [Installing dependencies using Pip] Using cached pip download/wheel cache Running pip install Collecting click==7.1.2 (from -r requirements.txt (line 1)) Using cached click-7.1.2-py2.py3-none-any.whl.metadata (2.9 kB) Collecting Flask==1.1.2 (from -r requirements.txt (line 2)) Using cached Flask-1.1.2-py2.py3-none-any.whl.metadata (4.6 kB) Collecting gunicorn==20.0.4 (from -r requirements.txt (line 3)) Using cached gunicorn-20.0.4-py2.py3-none-any.whl.metadata (3.5 kB) Collecting itsdangerous==1.1.0 (from -r requirements.txt (line 4)) Using cached itsdangerous-1.1.0-py2.py3-none-any.whl.metadata (3.1 kB) Collecting Jinja2==2.11.3 (from -r requirements.txt (line 5)) Using cached Jinja2-2.11.3-py2.py3-none-any.whl.metadata (3.5 kB) Collecting MarkupSafe==1.1.1 (from -r requirements.txt (line 6)) Using cached MarkupSafe-1.1.1-cp312-cp312-linux_x86_64.whl Collecting Werkzeug==1.0.1 (from -r requirements.txt (line 7)) Using cached Werkzeug-1.0.1-py2.py3-none-any.whl.metadata (4.7 kB) Requirement already satisfied: setuptools>=3.0 in /layers/heroku_python/python/lib/python3.12/site-packages (from gunicorn==20.0.4->-r requirements.txt (line 3)) (68.0.0) Using cached click-7.1.2-py2.py3-none-any.whl (82 kB) Using cached Flask-1.1.2-py2.py3-none-any.whl (94 kB) Using cached gunicorn-20.0.4-py2.py3-none-any.whl (77 kB) Using cached itsdangerous-1.1.0-py2.py3-none-any.whl (16 kB) Using cached Jinja2-2.11.3-py2.py3-none-any.whl (125 kB) Using cached Werkzeug-1.0.1-py2.py3-none-any.whl (298 kB) Installing collected packages: Werkzeug, MarkupSafe, itsdangerous, gunicorn, click, Jinja2, Flask Successfully installed Flask-1.1.2 Jinja2-2.11.3 MarkupSafe-1.1.1 Werkzeug-1.0.1 click-7.1.2 gunicorn-20.0.4 itsdangerous-1.1.0 ===> EXPORTING Adding layer 'heroku/python:dependencies' Adding layer 'heroku/python:python' Adding layer 'buildpacksio/lifecycle:launch.sbom' Adding 1/1 app layer(s) Adding layer 'buildpacksio/lifecycle:launcher' Adding layer 'buildpacksio/lifecycle:config' Adding label 'io.buildpacks.lifecycle.metadata' Adding label 'io.buildpacks.build.metadata' Adding label 'io.buildpacks.project.metadata' ERROR: failed to export: determining entrypoint: tried to set web to default but it doesn't exist

步骤失败

[edmorley]

@manong-detective Hi!

The Python CNB doesn't set any process types/entrypoints, since there isn't a sensible default we can pick (unlike say Node.js apps, where conventions like the package.json scripts.start entry can be used if it is set). As such, for Python apps any process types must be defined via a Procfile, which will get picked up by the Procfile CNB.

From the logs above, I see the Procfile CNB didn't run:

===> DETECTING
1 of 2 buildpacks participating
heroku/python 0.8.4

If it had run, the output would have shown:

===> DETECTING
heroku/python   0.8.4
heroku/procfile 3.0.1
...
===> BUILDING
...
[Discovering process types]
Procfile declares types -> web
===> EXPORTING
...

This means there was no Procfile found in the root directory of the application source.

However, the Procfile being missing (and so the Procfile CNB not running) does not normally result in an error.

For example, if I locally use Pack CLI to build then the build still succeeds (the image will just not have a default process configured, so when I launch the image I'd need to specify a command manually):

$ git clone https://github.com/heroku/python-getting-started && cd python-getting-started
$ rm Procfile
$ pack build --builder heroku/builder:22 python-test
...
===> DETECTING
1 of 2 buildpacks participating
heroku/python 0.8.4
===> RESTORING
===> BUILDING
...
===> EXPORTING
Adding layer 'heroku/python:dependencies'
Adding layer 'heroku/python:python'
Adding layer 'buildpacksio/lifecycle:launch.sbom'
Adding 1/1 app layer(s)
Adding layer 'buildpacksio/lifecycle:launcher'
Adding layer 'buildpacksio/lifecycle:config'
Adding label 'io.buildpacks.lifecycle.metadata'
Adding label 'io.buildpacks.build.metadata'
Adding label 'io.buildpacks.project.metadata'
no default process type
Saving python-test...
*** Images (401af57dbb7e):
      python-test
Adding cache layer 'heroku/python:pip-cache'
Adding cache layer 'heroku/python:python'
Successfully built image python-test

As such, this seems like a bug with the Tekton integration itself, since this works fine with Pack CLI.

I would recommend filing an issue here: https://github.com/buildpacks/tekton-integration/issues

To work around the Tekton integration bug in the meantime, make sure to add a Procfile to your app. For more info, see: https://github.com/heroku/buildpacks-procfile https://devcenter.heroku.com/articles/procfile

But using gcr.io/buildpacks/builder: v1 and paketobuildpacks/builder: base is ok, don't know is what reason

I presume this is because the Paketo Python CNB sets a default process (of running the Python repl, which I'm not sure really makes much sense for most apps) - so if an app hasn't set process types of its own (via eg a Procfile), then there will always be a default entrypoint: https://github.com/paketo-buildpacks/python https://github.com/paketo-buildpacks/python-start

[manong-detective]

Anyway, to work around the Tekton integration bug, make sure to add a Procfile to your app. For more info, see: https://github.com/heroku/buildpacks-procfile https://devcenter.heroku.com/articles/procfile

Yes, adding Procfile does solve the error, but it just feels a little bit less intelligent, like other builders don't need to write their own procfile feels better

[edmorley]

Is the default entrypoint of running the Python repl (the interactive Python terminal) really a useful default though?

It seems most of the time you would need to manually specify your own command, in which case it's identical to not setting a default (ignoring the Tekton integration bug).

[manong-detective]

Is the default entrypoint of running the Python repl (the interactive Python terminal) really a useful default though?

It seems most of the time you would need to manually specify your own command, in which case it's identical to not setting a default (ignoring the Tekton integration bug).

ok, there is nothing wrong with specifying a profile. It is true that in most cases you still have to specify it yourself. Thank you for your answer

[edmorley]

I've reported the Tekton integration bug upstream, at: https://github.com/buildpacks/tekton-integration/issues/41

Closing this out since this was an upstream bug, and there is a workaround (adding a Procfile).