Updated Faraday

[andsel]

No description provided.

[github-actions]

🤖 GitHub comments

Just comment with:

• run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)
• run exhaustive tests : Run the exhaustive tests Buildkite pipeline.

[kaisecheng]

LGTM

[donoghuc]

I'm not following this change? Why is this addition being added to the gemspec? If we want to simply ship a newer faraday, we should just update our gemfile.lock for this stream. Along that line I would expect a corresponding update

logstash/Gemfile.jruby-3.1.lock.release

Line 130 in 96f4035

faraday (2.13.4)

if we are going to change the gemspec. Generally though carrying new dependencies in the gemspec seems overkill for this.

[mashhurs]

Gemfile.lock contains 2.13.x version. I think we should update that as well?!

[mashhurs]

I'm not following this change? Why is this addition being added to the gemspec? If we want to simply ship a newer faraday, we should just update our gemfile.lock for this stream. Along that line I would expect a corresponding update

logstash/Gemfile.jruby-3.1.lock.release

Line 130 in 96f4035

faraday (2.13.4)

if we are going to change the gemspec. Generally though carrying new dependencies in the gemspec seems overkill for this.

🤦 Ah, didn't see this comment! Sorry for noise.

[andsel]

@donoghuc If we update the gemspec we have a clear statement of the requirement I think, and next time we run the bump dependencies GH action (https://github.com/elastic/logstash/actions/workflows/version_bumps.yml) then the lock file should be updated contextually. But I could be wrong.

[donoghuc]

@andsel I am hesitent to start pulling transitive dependencies into the top level of the gemspec. Over time it becomes really difficult to reason through what logstash dependencies we actually have. If for example the gem for which faraday is a truly a dependency of (therefore a transitive dependency to logstash) moves on from Faraday, or bumps to the next major version we will risk a conflict.

IMO, we have the gemfile.lock pattern for this exact use case: Control exactly what gems we ship (rather than just the latest). The gemspec should be reserved for true top level dependencies or pinning to very specific versions (and that second use case could be argued for the Gemfile.template.

[elasticmachine]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: ad5a814

Failed CI Steps

• 🥼 Integration Tests - FIPS mode / part 4-of-6
• 🥼 Integration Tests - FIPS mode / part 4-of-6

History

• 💛 Build #4329 was flaky a51c90d

cc @andsel