chore: Fix Gemfile versions to avoid Gemfile.lock updates #1047
Conversation
| gem "lefthook", "~> 1.10" | ||
| gem 'danger', '9.5.1' | ||
| gem 'rest-client', '2.1.0' | ||
| gem "lefthook", "1.10.10" |
There was a problem hiding this comment.
Hmm I actually think we are leaving these with the version unspecified so we can get auto-updates from dependabot. Since they are only related to CI, it's mostly ok to get auto-updates... Are you getting any issues with the updates?
There was a problem hiding this comment.
Well, I am used to fixing versions in any Gemfile. I tried running a fastlane command locally, and ended up with an updated lock file.
Does this prevent updates? I am used to dependabot opening PRs whenever there's an update. I think we might just need to add a few more lines to dependabot.yml
That keeps track of any change, and we can control what we update and when we update. Great to avoid unexpected broken release trains.
There was a problem hiding this comment.
Hmm strange... in general, the lock file should already specify the dependency versions used (part of the reason we are checking it in the repo), so it shouldn't update dependencies automatically... What dependecies were updated?
I totally agree about locking dependencies that are used in our main SDKs, but considering these are mostly for automations and we have the lock files, I think it's better to try to get auto-updates... I believe dependabot only updates dependencies within the constraints specified in the Gemfile? I might be wrong but I would consider it an issue if it bumped dependencies to next majors which might not be compatible (I could actually see an argument to lock our dependencies to the current major instead, so dependabot doesn't try to auto-update beyond that). Wdyt?
This PR fixes the Gemfile to avoid unnecessary .lock updates