buildpacks-ruby
buildpacks-ruby copied to clipboard
Missing `Gemfile.lock` error includes `ls: cannot access 'la': No such file or directory`
STR:
mkdir testcase && cd $_touch Gemfilepack build --buildpack heroku/ruby testcase
Expected
- Error message that explains
Gemfile.lockis 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:
- Fix the args to
ls(to use-lainstead ofla) - Add
libcnb-testintegration 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) - 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