Skip to content

Missing Gemfile.lock error includes ls: cannot access 'la': No such file or directory #388

@edmorley

Description

@edmorley

STR:

  1. mkdir testcase && cd $_
  2. touch Gemfile
  3. pack build --buildpack heroku/ruby testcase

Expected

  • Error message that explains Gemfile.lock is missing, and for bonus points includes the directory listing of the source.
  • For that error message not to include any additional errors or warnings generated whilst rendering the error message.

Actual

===> BUILDING

## Heroku Ruby Buildpack

- Could not find `/workspace/Gemfile.lock`, details:
  - failed to open file `/workspace/Gemfile.lock`: No such file or directory (os error 2)
- Debug info Contents of the `/workspace` directory
  - Running debug command `ls la /workspace`

      ls: cannot access 'la': No such file or directory
      /workspace:
      Gemfile
      README.md
      bin

  - Done (< 0.1s)
  - Command failed `ls la /workspace`
    exit status: 2
    stdout: <see above>
    stderr: <see above>

! Error: `Gemfile.lock` not found
!
! A `Gemfile.lock` file is required and was not found in the root of your application.
!
! If you have a `Gemfile.lock` in your application, ensure it is tracked in Git and
! that you’re pushing the correct branch.
!
! For more information:
! https://devcenter.heroku.com/articles/git#deploy-from-a-branch-besides-main

Note the ls: cannot access 'la': No such file or directory.

Suggested next steps:

  1. Fix the args to ls (to use -la instead of la)
  2. Add libcnb-test integration test coverage of the full output here (such a test would be fast to run, since it's a failure right at the start of the build, plus IMO the error messages around onboarding an app to the CNB are high priority for UX/DX and so worth ensuring all are tested)
  3. Ideally reducing some of the unnecessary repetition in the build output. For example there's a lot of duplication around Could not find + No such file or directory (os error 2) before the actual error message. For some other type of I/O error, there is value in exposing the underlying error, but for this "file not found" case I don't think that pre-amble is needed (the only useful part of it is the absolute path to the Gemfile.lock, which could be inlined in the actual error message etc).

cc @schneems

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions