In our case, and in most cases, I don't see a point for an application to repeat constraints in `Gemfile` and `Gemfile.lock`, where the former gets automatically updated by a program anyway. Most of our `gem` requirements are written in this way to begin with, but fix those that aren't while changing the strategy. The upshot of this is, when a requirement (e.g. due to an incompatible new version) really does need to be specified, it is effective, and Dependabot doesn't go about updating the `Gemfile` to render the restriction ineffective.
45 lines
967 B
YAML
45 lines
967 B
YAML
version: 2
|
|
updates:
|
|
- package-ecosystem: 'bundler'
|
|
directory: '/'
|
|
schedule:
|
|
interval: 'daily'
|
|
versioning-strategy: lockfile-only
|
|
allow:
|
|
- dependency-type: "all"
|
|
groups:
|
|
production-dependencies:
|
|
dependency-type: "production"
|
|
development-dependencies:
|
|
dependency-type: "development"
|
|
- package-ecosystem: 'npm'
|
|
directory: '/'
|
|
schedule:
|
|
interval: 'weekly'
|
|
allow:
|
|
- dependency-type: "all"
|
|
groups:
|
|
js-dependencies:
|
|
patterns:
|
|
- "*"
|
|
- package-ecosystem: 'docker'
|
|
directory: '/'
|
|
schedule:
|
|
interval: 'weekly'
|
|
allow:
|
|
- dependency-type: "all"
|
|
groups:
|
|
docker-dependencies:
|
|
patterns:
|
|
- "*"
|
|
- package-ecosystem: 'github-actions'
|
|
directory: '/'
|
|
schedule:
|
|
interval: 'weekly'
|
|
allow:
|
|
- dependency-type: "all"
|
|
groups:
|
|
github-actions-dependencies:
|
|
patterns:
|
|
- "*"
|