Upgrade Faraday for CVE#76
Conversation
Also removed constraints where possible
…nto issue/75-dependencies-upgrade
Test against rubies 3.3 to 4.0.
Apply Rubocop corrections.
|
Does this in some way address #74 now? |
Yes, well spotted. We should be able to write up some process or good practice for updating Gems too. |
joescottdave
left a comment
joescottdave
left a comment
There was a problem hiding this comment.
Questions about some of the places we're specifying 3.3 - I think it makes sense as the baseline for the required version, and we're testing it in the matrix, but elsewhere probably makes sense to be using the latest version (that we support)
| uses: ruby/setup-ruby@v1 | ||
| with: | ||
| ruby-version: 2.7 | ||
| ruby-version: 3.3 |
There was a problem hiding this comment.
Can this be 3.4 now? I think things have moved on from when the tickets were written
| @@ -1,5 +1,5 @@ | |||
| AllCops: | |||
| TargetRubyVersion: 2.7 | |||
| TargetRubyVersion: 3.3 | |||
There was a problem hiding this comment.
Should maybe be 3.4 also ?
| @@ -1 +1 @@ | |||
| 2.7.8 | |||
| 3.3.11 No newline at end of file | |||
Good question. We want to explicitly support the currently in-support versions of Ruby, so the 3.3, 3.4 and 4.0 series as of writing. For Gems that are used by other apps, it makes sense to be compatible with these versions and test that the Gems work across the versions. For linting/Rubocop, I guess these will pick up newer constraints and issues with newer Rubies if we bump the target version and there shouldn't be any harm in that, as long as they are backward compatible with the minimal version we specify? We could, for instance, put the linting/Rubocop checks in the same matrix loop as the tests. That might highlight whether things are backward compatible. The supported version range is specified in the gemspec and I don't think the |
…default Ruby in the GH runner. Move Rubucop to matrix so it'll run using the latest in 3.3 and 3.4 series Rubies.
joescottdave
left a comment
joescottdave
left a comment
There was a problem hiding this comment.
Looks good from my perspective
ajtucker
left a comment
ajtucker
left a comment
There was a problem hiding this comment.
Before we merge, I need to check the Rubocop linting...
…te the test runs. Remove targetRubyVersion from Rubocop config as it will conservatively use the minimal version from the gemspec. Avoid re-running Rubocop for anything other than the minimal Ruby version in the matrix.
ajtucker
left a comment
ajtucker
left a comment
There was a problem hiding this comment.
I can't quite pin it down, but https://docs.rubocop.org/rubocop/latest/configuration.html#setting-the-target-ruby-version has mention that we need to set the RuboCop target to the minimal/oldest version of Ruby that we want to support in order that we don't fall foul of e.g. newer recommended syntax that isn't support in older versions.
4 participants
This PR addresses issue #75 by upgrading Faraday to resolve https://github.com/epimorphics/sapi-client-ruby/security/dependabot/15, as well as the other dependencies. I've also moved all development dependencies from the
gemspecfile into theGemfileand removed version constraints where possible