ci: Update gemspec dependencies using renovate#2031
ci: Update gemspec dependencies using renovate#2031thompson-tomo wants to merge 6 commits intoopen-telemetry:mainfrom
Conversation
thompson-tomo
requested review from
a team,
ahayworth,
arielvalentin,
dazuma,
ericmustin,
fbogsany,
kaylareopelle,
mwear,
plantfansam,
robbkidd,
robertlaurin,
simi and
xuan-cao-swi
as code owners
thompson-tomo
force-pushed
the
ci/update_gemspecs
branch
3 times, most recently
from
854c062 to
93c3202
Compare
thompson-tomo
changed the title
.github/renovate.json5
Outdated
| description: "Update dependencies in gemspecs", | ||
| managerFilePatterns: ["**/*.gemspec"], | ||
| matchStrings: [ | ||
| ".add_(?<depType>.*dependency)\\s'(?<packageName>.+?)',\\s'\\S+\\s(?<depVersion>[0-9.]+)'", |
There was a problem hiding this comment.
Does renovate not update gempsecs by default or does it only do it for Gemfiles.
Either way, we only want to keep runtime dependencies in the gem spec so add_dependency is sufficient without needing depType.
Development dependencies should be declared in Gemfiles.
If you find an inconsistency please update the Gemspec to use a Gemfile instead.
There was a problem hiding this comment.
Does renovate not update gempsecs by default or does it only do it for Gemfiles.
Correct no support for gemspecs out of the box as per #1803.
Either way, we only want to keep runtime dependencies in the gem spec so add_dependency is sufficient without needing depType.
DepType is the name of regex capture group which appears in pr's and can be used in rules.
Development dependencies should be declared in Gemfiles.
If you find an inconsistency please update the Gemspec to use a Gemfile instead.
I don't believe there were many if any in contrib, however in otel-ruby dev dependencies are widely used and my intention was once these pr's done we/I monitor the behaviour for a couple of weeks before syncing the renovate rules and managers across.
There was a problem hiding this comment.
Removing development dependencies from gemspecs is something I'd like to do in the core repo as well. Hopefully that will make the repos a bit more symmetric.
There was a problem hiding this comment.
Sure, I agree that the more consistent the repos are the better so all for updating core. The question is, do I need to remove the package rule which allows dev dependencies to bypass manual approval to be created?
There was a problem hiding this comment.
I think so. It makes it simpler for me to read and know will communicate to others that renovate will only update add_dependency declarations and ignore undesirable add_runtime_dependency and add_development_dependency
There was a problem hiding this comment.
Ok, so based on that description I have removed the rule which handled dev dependencies in a different manner to non dev and instead added a rule which explicitly disabled non dependency updates. This way it is clearer that they have been disabled.
There was a problem hiding this comment.
Am I misunderstanding something? The capture group is still there.
There was a problem hiding this comment.
You are correct the capture group is still there to avoid hard coding it. The custom manager just enables the dependency to be detected and listed in the dashboard.
The package rules are what control if update pr's are raised and in the case here we have a rule which explicitly blocks all updates to gemfiles if they are not a dependency update. This means that dependencies added via add_development_dependency won't be updated but a add_dependency would be.
thompson-tomo
force-pushed
the
ci/update_gemspecs
branch
2 times, most recently
from
a9ad461 to
29cfeca
Compare
thompson-tomo
force-pushed
the
ci/update_gemspecs
branch
from
29cfeca to
7476900
Compare
thompson-tomo
force-pushed
the
ci/update_gemspecs
branch
from
936682d to
7476900
Compare
thompson-tomo
force-pushed
the
ci/update_gemspecs
branch
from
0cbfcee to
43c9caf
Compare
2 participants
Add in custom manager which detects dependencies in gemspecs and then ensure we have rules which updates them like bundler