Handle Errno::EPERM errors when composing bundle#3698
Conversation
How to use the Graphite Merge QueueAdd the label graphite-merge to this PR to add it to the merge queue. You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
egiurleo
force-pushed
the
ignore-operation-not-permitted
branch
from
bc30fa2 to
d638388
Compare
egiurleo
added
server
| return | ||
| rescue Errno::EPERM | ||
| # If the user doesn't have permission to perform read operations, we can't compose the bundle | ||
| return |
There was a problem hiding this comment.
Let me know if it makes sense to return here -- my understanding is we can't compose the bundle without more permissions.
There was a problem hiding this comment.
It will depend on why we're getting the permission issue. When you invoke Bundler.default_lockfile, it will keep searching for a Gemfile and Gemfile.lock pair in parent directories until it reaches home.
Are we 100% sure that the permission issue is coming from reading the lockfile and not from trying to read the parent directories?
The issue could be that there's simply no bundle in the project and the user didn't give permissions to the editor for accessing any of the parent directories. In that case, returning early would not be correct because we can still compose the bundle as long as there's no lockfile and the user has permissions for the current directory.
Some of these errors have been reported to our telemetry. For now, it makes sense to rescue the error and ignore it because it means that the user's environment does not have permissions to read their lockfile, which means we can't compose the bundle.
egiurleo
force-pushed
the
ignore-operation-not-permitted
branch
from
d638388 to
f0b38fd
Compare
|
This pull request is being marked as stale because there was no activity in the last 2 months |
2 participants
Motivation
We have
Errno::EPERMerrors being reported on telemetry when the server attempts to compose the bundle. This happens when the user's environment does not have permissions to read theirGemfile.lock.Implementation
This rescues the error and then returns from the
compose_bundlemethod as we likely do not have sufficient permissions to finish.Automated Tests
I've added an automated test.