Check for default gemfile instead on bundler directory

[smedrick]

What does this pull request do?

When the stacktrace helper attempts to find the path of installed gems, it uses a method to verify a default bundler install path that attempts to write to the filesystem. This behavior prevents the apm agent from running on a read-only filesystem. This PR attempts to keep the spirit of the functionality while getting around the need to write to the filesystem. Instead of checking if there is a default bundler path, it checks to see if there's a default gemfile.

Why is it important?

Without this bug fix, we cannot run the agent on apps in our secure k8s cluster.

Checklist

• I have signed the Contributor License Agreement.
• My code follows the style guidelines of this project (See .rubocop.yml)
• I have rebased my changes on top of the latest main branch

• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

• I have made corresponding changes to the documentation
• I have updated CHANGELOG.asciidoc
• I have updated supported-technologies.asciidoc
• Added an API method or config option? Document in which version this will be introduced

Related issues

• Closes 1464

[cla-checker-service]

💚 CLA has been signed

[estolfo]

Hi @smedrick thanks for this PR. Did you find this as the result of an error? I just wanted to see if I could reproduce it. Also, if you could sign the CLA, that'd be great.

[smedrick]

Hi @smedrick thanks for this PR. Did you find this as the result of an error? I just wanted to see if I could reproduce it. Also, if you could sign the CLA, that'd be great.

This addresses #1464

I did sign the CLA but I have no idea how it links back to the PR

[smith]

I did sign the CLA but I have no idea how it links back to the PR

I tried to re-run the check and it came back as not signed. Since this PR is over a year old I'm going to close it but can reopen and merge if CLA is detected.

[smedrick]

The project went a year without a released change, that's an odd reason to close the PR. Your CLA system is broken and we can't follow your sparse updates without this fix.

[smith]

@smedrick I was not aware the CLA system is broken. I'm happy to reopen this and help get it resolved.

[smith]

@smedrick I think the CLA checker might be failing because on https://github.com/elastic/apm-agent-ruby/pull/1477/commits I see that 8acfac1 was authored by "Rick Watkins" (with no contact info) and daf6704 is authored by @smedrick, who does show up in Elastic's internal CLA checker.

I think squashing those commits and having only ones authored by @smedrick will make the CLA check pass. If that doesn't work we can try something else.