Config-help: Configuration review for Financial-Times

[sjparkinson]

Hi Rhys, would love to get your eyes on our first draft of a configuration.

For some background, we're looking to setup Renovate on a subset of repositories (those that back FT.com and the apps) in the Financial-Times org.

They are all npm based projects, build with CircleCI.

We're cautious of creating noise, so want to limit the scope of what's managed initially. Bringing more into the fold as we gain confidence in this new way of working.

• No dev dependency management
• Pin @financial-times scoped packages
• Group @financial-times scoped package upgrades
• Use semver ranges to manage third-party dependencies, so only PRs for major version upgrades
• No CircleCI Docker image management for now

{
  "extends": [
    "config:base",
    ":onlyNpm",
    ":disableDevDependencies"
  ],
  "labels": [
    "dependencies"
  ],
  "rangeStrategy": "replace",
  "packageRules": [
    {
      "packagePatterns": [
        "@financial-times"
      ],
      "groupName": "financial-times",
      "rangeStrategy": "pin"
    }
  ]
}

I _think_ that's what this configuration would enable, but if there are any side-effects I've not spotted I'd love to know!

---

We're also just getting the ball rolling with our procurement process, for an Organization Large plan (though if other teams want in we may need more than 100 repositories next year).

You may get a few emails from the team, hope that's OK.

[rarkins]

Hi Samuel, glad you have made great progress with Renovate. Here are my thoughts:

Assuming you want the same rules across the whole org or teams, the best thing would be to create your own "preset" that all repositories will use. That way whenever you make updates to your rules you can make them in one place and they propagate. Presets can be published to npm or just hosted on a regular GitHub repo - whichever you prefer. GitHub hosting is a little light on documentation so let me know if you choose that and want guidance.

I recommend you remove the config:base preset and explicitly include any of its subrules that you need.

These sub-presets are not default bot behaviour so need to be included if you want this functionality:

    ":semanticPrefixFixDepsChoreOthers",
    ":ignoreModulesAndTests",
    ":autodetectPinVersions",
    ":prHourlyLimit2",
    ":prConcurrentLimit20",
    "group:monorepos",
    "group:recommended",

:semanticPrefixFixDepsChoreOthers will mean fix(deps): prefix is used for dependencies and build(deps) for devDependencies. You may want to customise that or maybe even turn such prefixes permanently off. Either way, it's good to explicitly add a semanticCommits true/false setting so it's clear and not at risk of inconsistency between projects if some use it and some don't.

With autodetectPinVersions you will see devDependencies always pinned and dependencies pinned only if the repository is detected to be a non-library. I suggest you don't include this preset so that there's no risk of it interfering with your rangeStrategy settings.

You can also limit PRs raised per hour, and concurrent PRs. The above presets are for 2 per hour and 20 concurrent respectively.

The final two presets group together related libs and I definitely recommend you keep those.

I can't really comment on if grouping of @financial-times packages is a good idea or not but that rule will certainly do what you describe.

Use semver ranges to manage third-party dependencies, so only PRs for major version upgrades

The downside of this approach is that - assuming you use a lockfile - you will usually end up locking your versions to something quite old. Consider Renovate's "lock file maintenance" feature in that case, at least once a month.

Totally disabling devDependencies will definitely decrease noise as you wish. However you might want to instead consider using a "master issue" to track all pending and open PRs, and set all devDependencies to require approval. That way no PRs are automatically created for devDependencies - just like if you disable them - but you can see what you're missing out on, and trigger a PR manually with just a single click. I haven't announced/documented the feature yet but have been dogfooding it in my own repos and a few others have enabled it too, including the Yarn project. You can see an example "master issue" here: https://github.com/renovatebot/renovate/issues/2599

To configure a master issue with approvals only for devDependencies, remove :disableDevDependencies and include this instead:

  "masterIssue": true,
  "packageRules": [{
    "depTypeList": ["devDependencies"],
    "masterIssueApproval": true
  }]

Re: the account, no problem with emails - shoot away.

[sjparkinson]

Absolutely fantastic, and thank you for the advice, your comment on grouping our packages is helpful.

[sjparkinson]

GitHub hosting is a little light on documentation so let me know if you choose that and want guidance.

That'd be helpful actually. I've had a stab with one project.

We've setup https://github.com/Financial-Times/n-renovate.

And on the project we have:

--- a/package.json
+++ b/package.json
@@ -10,6 +10,7 @@
   "devDependencies": {
     "@financial-times/n-gage": "^2.0.2",
     "@financial-times/n-heroku-tools": "^7.2.0",
+    "renovate-config-next": "github:financial-times/renovate-config-next",
     "fetch-mock": "^6.4.2",
     "haikro": "^2.3.4",
     "jest": "^20.0.0",
diff --git a/renovate.json b/renovate.json
index f45d8f1..fe71a87 100644
--- a/renovate.json
+++ b/renovate.json
@@ -1,5 +1,5 @@
 {
   "extends": [
-    "config:base"
+    "next"
   ]
 }

[rarkins]

GitHub-hosted presets currently support only a single (default) preset per repo. Here’s what you need to do:

• in the preset repo financial-times/renovate-config-next, move its preset config into a renovate.json file (not package.json)
• in other repos, add “github>financial-times/renovate-config-next” to the extends array

github> signifies the type, then the repo, and renovate.json is implied.

[rarkins]

I expanded the docs here:
https://github.com/renovatebot/renovate/blob/master/website/docs/config-presets.md

[rarkins]

@sjparkinson one other thing: once you do have a preset you want to share amongst your repositories, you can ask me to set it as your default onboarding config for all financial-times/* repositories - I need to add it manually on the server side. That way each new repository could have the default config of {extends:["@financial-times"]} in the "Configure Renovate" PR instead of {extends:["config:base"]}

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed soon if no further activity occurs.

[rarkins]

@sjparkinson FYI, I noticed something in the logs you should be aware of. In one of your installed repositories (it starts with "next-") there existed a branch called "renovate". Having a branch named "renovate" actually blocks the creation of any "renovate/*" branch due to the way git works, so Renovate's default behaviour is to nuke such a branch if found.. which it did.

[sjparkinson]

Ah! Yep I've hit that at my last workplace before 😅.

Thanks for the heads up, I think I've done that a couple of times now, though nothing to worry about.

Thanks for merging my grouping PR too!

All going really well our end, noticed some delays yesterday but no biggie.

Procurement is also happening, but I've been told it isn't always the fastest process.

once you do have a preset you want to share amongst your repositories, you can ask me to set it as your default onboarding config for all financial-times/* repositories

I don't think I'll ask for that, as we have quite a number of other teams also working under the Financial-Times org, who won't like our defaults. But thank you.

[sjparkinson]

Also, feedback for the master issue. Though I'd guess this might be coming anyway.

Would be good, if a PR existed, to have these link too. We're finding that we have comments on the PR to explain why we've closed it.

[rarkins]

Good idea, I’ve added a feature request for that

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed soon if no further activity occurs.