Automate Configuration Migrations

[ghost]

Recently I've noticed the following output for a few projects using an on-premise deployment of Renovate:

INFO: Config migration necessary (repository=example-project)
      "oldConfig": {
        "extends": [
          ":separateMajorReleases",
          ":prImmediately",
          ":renovatePrefix",
          ":semanticPrefixFixDepsChoreOthers",
          ":updateNotScheduled",
          ":automergeDisabled",
          ":maintainLockFilesDisabled",
          ":autodetectPinVersions",
          "group:monorepos",
          "helpers:oddIsUnstablePackages"
        ],
        "pinVersions": false,
        "semanticCommits": true,
        "timezone": "US/Central",
        "baseBranch": "development",
        "schedule": ["after 8am and before 5pm on sunday"]
      },
      "newConfig": {
        "extends": [
          ":separateMajorReleases",
          ":prImmediately",
          ":renovatePrefix",
          ":semanticPrefixFixDepsChoreOthers",
          ":updateNotScheduled",
          ":automergeDisabled",
          ":maintainLockFilesDisabled",
          ":autodetectPinVersions",
          "group:monorepos",
          "helpers:oddIsUnstablePackages"
        ],
        "pinVersions": false,
        "semanticCommits": true,
        "timezone": "US/Central",
        "schedule": ["after 8am and before 5pm on sunday"],
        "baseBranches": ["development"]
      }

It looks like the property baseBranches changed.

Would it be possible to have Renovate automate the process of upgrading a project's configuration for these minor changes?

Perhaps submitting a pull request with the new, migrated, configuration. Also auto-accept in the event that the change is non-breaking, and status checks pass?

[rarkins]

It’s definitely my plan to raise a PR for this, but I want to review quite a few logs first to make sure they’re right. I know of one bug with it for instance (empty errors array gets appended sometimes). For the app I probably won’t make automerge the default but it could be configurable for self hosted users to enable.

[ghost]

We definitely have a small, but growing number, of repositories with minor configuration changes indicated by Renovate.

Our hope is to keep our overhead low on the side of the team deploying Renovate, and to be consistent in how we communicate configuration changes (through automated PRs).

Having it off by default would be fine with me, as it would be easy enough to enable in our on-premise deployment.

[HonkingGoose]

@rarkins You said in PR #10426:

We've generally kept migrations "forever". We really should implement the config migration PR so that in future we can remove migrations after a reasonable time.

Maybe you want to bump the priority of this issue to priority-2-important?

[rarkins]

For now I'm classifying this as status:blocked because I want to complete the refactoring of migration code first, so that key ordering is preserved as much as possible. Without it, migration PRs will be harder to read.

[rarkins]

Blocked by #11459

[rarkins]

I think this can be unblocked now, and we should release it using a feature flag migrateConfigurations, which defaults to false.

[rarkins]

The branch name should be {{{branchPrefix}}}migrate-config.

[Gabriel-Ladzaretti]

I've did some research and fiddled around.

One approach I tried was to hook into the main flow of renovate with custom manager, datasource and versioning.
Configuration entry is treated as a dependency and the value as a version, and using the replacementName and replacementVersion mechanism to update it.

This approach happens to be quite cumbersome , as the migrated config can have deleted lines or renamed value pairs and a lot of extra housekeeping is needed for this one to work.

one other solution is to simply write to a file the updated migrated config and create a PR for it.
in this approach parsing is not needed and user's indention might be overwritten.

Would appreciate your input on this and as to how to proceed further

[rarkins]

We can detect the user's indentation. There's already a library for this which we use in a couple of places.

[Gabriel-Ladzaretti]

This is only a POC, there is still much to be done.
but we are getting somewhere
https://github.com/ladzaretti/config-migration/pull/3/files

done via the manager -> datasource -> versioning route

[rarkins]

I think this might be over complicating things. We just want a standalone PR similar to how onboarding ones are done. Unrelated to managers, datasources and versioning

[renovate-release]

🎉 This issue has been resolved in version 32.90.0 🎉

The release is available on:

• GitHub release
• 32.90.0

Your semantic-release bot 📦🚀