Renovate: Cyclic dependency updates: Avoid `fix(deps)` semantic PRs for examples

Created on 29 Dec 2017  路  5Comments  路  Source: renovatebot/renovate

First of all, thank you so much for this great tool & service. It's continuously saving us a lot of time and frustration. 馃檶

We've recently introduced semantic-release for most of our open-source libraries but are running into one common problem. Let's assume the following repo structure (package called my-lib):

package.json
src/
  index.js
example/
  package.json
  index.js

renovate does a great job at keeping both the dependencies of my-lib and the example using my-lib up to date. However, when a new NPM version of my-lib is published, renovate automatically creates a PR for the example updating my-lib to the new version - which is great and exactly what I want.

The only problematic thing here is that it does so by using a semantic commit (e.g. fix(deps): update dependency my-lib to v0.5.6 which on it's own will lead to a new version of my-lib which will cause an infinite release cycle.

So here are a couple of questions/thoughts:

  • It would be great if renovate detects these kinds of setups automatically and doesn't create a semantic commit for example folders
  • One way to solve this might be by using a mono-repo setup of semantic-release (like this fork), however, this would mean quite a lot of overhead.

Possibly related to #1308

priority-3-normal feature

All 5 comments

I suppose the ideal would be to bump the version within example in the same PR, however that would require some pretty advanced logic that I'm probably not ready to implement yet (would want to wait until I have an elegant way to specify and configure it).

One suggestion I'd normally make is whether you might want to use a major range (e.g. ^1.0.0) within examples so that you can avoid that "second" PR each time, although it sounds like you might be happy to pin the my-lib version and get the PRs accordingly.

If ultimately you just wish to use chore instead of fix for examples/* then I think I can implement that fairly easily with a new config concept I've been intending to add for a while - pathRules. That way we could add a pathRule for examples/* to set all commit types to chore. I'll let you know once it's done.

If ultimately you just wish to use chore instead of fix for examples/* then I think I can implement that fairly easily with a new config concept I've been intending to add for a while - pathRules. That way we could add a pathRule for examples/* to set all commit types to chore. I'll let you know once it's done.

I think that would be a great option until you've come around to implement the more advanced logic 馃憣

You should now be able to achieve this if you update your config(s) to include the preset ":pathSemanticCommitType(examples/**,chore)" like so:

{
  "extends": [
    "config:base", 
    ":pathSemanticCommitType(examples/**,chore)"
  ]
}

The above is shorthand for applying the "chore" semantic commit type for all package files matching the glob "examples/**". It expands to the following raw config:

{
  "extends": ["config:base"],
  "pathRules": [
    {
      "paths": ["examples/**"],
      "extends": [":semanticCommitTypeAll(chore)"]
    }
  ]
}

BTW don't forget that if you end up applying the same configuration across many repositories, you might want to define your own config presets so you can just extend that in every repository instead. See https://renovateapp.com/docs/configuration-reference/config-presets#how-to-publish-preset-configs

I will close this issue for now, as for now I can't see a realistic way for Renovate to do this type of "reasoning" automatically and hence it will remain as an opt-in preset for now.

Was this page helpful?
0 / 5 - 0 ratings