Detection step for buildpack groups randomly failing

[iplog]

We started using this orb recently with some good results. However the pack-build command seems to be randomly failing.

For a given configuration looking like that:

version: '2.1'

orbs:
  buildpacks: buildpacks/pack@0.2.4

workflows:
  main:
    jobs:
      - buildpacks/build:
          builder: 'heroku/buildpacks:20'
          buildpacks: heroku/nodejs;tomh4/python-poetry;heroku/python
          image-name: foo
          image-file: foo.tgz
          working-directory: /home/circleci/project
          env-vars: POETRY_VERSION=1.1.12;POETRY_EXPORT_DEV_REQUIREMENTS=1;DISABLE_POETRY_CREATE_RUNTIME_FILE=1

Most of the times everything goes well but it happens that the pack-build command fails with the following output

20: Pulling from heroku/buildpacks

17ec1767: Pulling fs layer 
9c8c3c2f: Pulling fs layer 
348e766f: Pulling fs layer 
568cbf74: Pulling fs layer 
90bafe4a: Pulling fs layer 
d7eb3657: Pulling fs layer 
5a93e214: Pulling fs layer 
efdf9bc9: Pulling fs layer 
0bede629: Pulling fs layer 
64ba3988: Pulling fs layer 
82f12387: Pulling fs layer 
568cbf74: Waiting fs layer 
918b0518: Pulling fs layer 
85bc9dfa: Pulling fs layer 
55b83bcd: Pulling fs layer 
db7d6f85: Pulling fs layer 
deff42eb: Pulling fs layer 
55ac2274: Pulling fs layer 
dafe4b03: Pulling fs layer 
d1b9aa75: Pulling fs layer 
fba38b67: Pulling fs layer 
78c5ff0a: Pulling fs layer 
57d1aa8b: Pulling fs layer 
1a26897a: Pulling fs layer 
1be9e73e: Pulling fs layer 
219d827e: Pulling fs layer 
9964778f: Pulling fs layer 
65d2946f: Pulling fs layer 
3958670f: Pulling fs layer 
aa0839f1: Pulling fs layer 
Digest: sha256:68502f93e41ffb23bded6f7119e3e2577cdf711f35acaf8c5dc823a11128ab8e
Status: Downloaded newer image for heroku/buildpacks:20
20: Pulling from heroku/pack

17ec1767: Already exists 
9c8c3c2f: Already exists 
348e766f: Already exists 
6ddb3fa7: Pulling fs layer 
Digest: sha256:69356f3937101029610c6931e194161b17b5445616a0162e65c86a28526c8334
Status: Downloaded newer image for heroku/pack:20
sha256:be2a4043243db931d991422a0a263cbffb5623579c4f77f3d22fe0a880dcacde: Pulling from tomh4/python-poetry-buildpack/tomh4_python-poetry

Digest: sha256:be2a4043243db931d991422a0a263cbffb5623579c4f77f3d22fe0a880dcacde
Status: Downloaded newer image for ghcr.io/tomh4/python-poetry-buildpack/tomh4_python-poetry@sha256:be2a4043243db931d991422a0a263cbffb5623579c4f77f3d22fe0a880dcacde
===> DETECTING
ERROR: No buildpack groups passed detection.
ERROR: Please check that you are running against the correct path.
ERROR: failed to detect: no buildpacks participating
ERROR: failed to build: executing lifecycle: failed with status code: 100

Exited with code exit status 1
CircleCI received exit code 1

Most of the time, running the failed job again is enough to get the command to pass. A few times we had to run the failed job again a couple of times to get it to pass.

I could not figure out why this is happening. It looks like the code is either not there or that the command is somehow not run from the right directory. Do you have any advice to give us?

Let me know if you need more information.

[jromero]

@iplog Did you try running a simple ls before the buildpacks/build job to ensure that the files you expect are present? Additionally, we could consider adding a verbose flag to the job so that it prints more information (if the buildpacks support it).

[iplog]

@jromero Thank you very much for your time and your answer.

I did not try to run a simple ls nor pwd (could have tries in the after-checkout hook I guess) butt the checkout of the code seemed to be successful according to the CircleCI report.

I think it would be great if the job could be a bit more verbose by default. It would be great if the job could output:

• the current path before it runs the pack command
• the final pack command returned by the create_command function in the pack-build job.

We decided to move back to our initial CI solution for now and are not using CircleCI anymore - nothing related to this issue. So this is not really an issue for us anymore. Feel free to close it.

[jromero]

@iplog Created #50 to track the request. Closing this issue for now.