Michael Kriese
654431d69f
* test(util/git): skip the per-test clone for tests that need no repo The spec's `beforeEach` rebuilds a bare clone and calls `initRepo()` before every test, which costs about 0.7s each. Eight tests never touch a repository at all -- `createSimpleGit`, `gitRetry`, `validateGitVersion` and `getUrl` -- yet each paid for that clone. They now sit in a second root describe with no clone in it, so the file drops from about 129s to about 121s with the same 144 tests. The two blocks that are pure functions are marked `describe.concurrent`. The other two stay sequential: `createSimpleGit` spies on a prototype and sets the custom env, and `gitRetry` stubs `NODE_ENV`. This was the outcome of trying `it.concurrent` across the file. It cannot help there, for two reasons stacked on each other. Vitest still runs `beforeEach` for every concurrent test, so concurrency does not remove the clone, it only interleaves several of them. And those interleaved clones all write the same module singleton (`config`, `git`, `gitInitialized`) and `GlobalConfig.localDir`, so one test's `initRepo()` is overwritten by another's before its body runs. The only lever that works is not running the clone for tests that do not need it. Co-Authored-By: Claude Fable 5.1 <michael.kriese+claude-code@mend.io> * test(util/git): share one clone across the read-only tests The spec now has one root describe with three nested groups, split by how much git setup a test needs: - `without a repository`: pure functions, no setup at all. - `shared clone`: 32 read-only tests. One bare clone of `base` and one `initRepo()` in `beforeAll`, so each test costs only the git commands it runs itself. - `clone per test`: the tests that commit, push, check out or re-init. They keep the fresh clone and `initRepo()` per test. The `base` repository moves up to the root describe so both clone groups can use it. Groups run in file order, and some of the writing tests change `base` without restoring it, so the shared-clone group has to stay ahead. `isBranchModified()` stays with the writing tests although it never touches the repository: it caches per-branch results in `config.branchIsModified`, which only `initRepo()` clears, and its tests query the same branch with different ignored authors. Three describes are split by test: `getFileList`, `getBranchUpdateDate` and `diffCommitTree` each have one test that writes, which stays behind under the same describe name with a pointer to the read-only half. Same 144 tests; the file drops from about 121s to about 100s. Co-Authored-By: Claude Fable 5.1 <michael.kriese+claude-code@mend.io> * test(util/git): keep the 30s test timeout for every test The `{ timeout: 30000 }` option used to sit on the single root describe and so covered every test in the file. The split left it on the `clone per test` group only, which put the 32 shared-clone tests on the 5s default even though they still run real git commands. CI is a lot slower than a local machine, so the option moves up to the root describe again; nested describes inherit it. Hooks are unaffected either way: they run under `hookTimeout`, not the suite option, and the shared `beforeAll` does the same work the old `beforeEach` did. Co-Authored-By: Claude Fable 5.1 <michael.kriese+claude-code@mend.io> * test(util/git): reuse one clone for the local-only writers A fourth nested group, `reused clone`, holds the 36 tests that write to the local checkout but never to `origin` or `base`: `checkoutBranch`, `isBranchModified`, `mergeToLocal`, `isFileModeEnabled`, `getCommitMessages`, `setGitAuthor`, `getRepoStatus`, `fetchRevSpec` and single tests of `getBranchUpdateDate`, `mergeBranch`, `deleteBranch` and `diffCommitTree`. The group clones once, but `initRepo()` and `syncGit()` run again before every test. On an existing checkout `syncGit()` takes its fetch path: `fetch --prune`, `reset --hard`, `checkout` of the default branch, `clean -fd` and deletion of every other local branch. With the fresh `config` from `initRepo()` that undoes everything such a test can do to the repository or the module singleton, including the per-branch `branchIsModified` cache that kept `isBranchModified()` out of the shared-clone group. Local git config is the one thing it leaves alone, so the `beforeEach` re-sets the author that `setGitAuthor()` writes. That reset costs about 0.35s per test against about 0.87s for a clone, so the file drops from about 100s to about 87s. Same 144 tests. Co-Authored-By: Claude Fable 5.1 <michael.kriese+claude-code@mend.io> * test(util/git): trim the describe comments to the essentials Review feedback: the block comments read more like a narration of how the layout came to be than like documentation. Each now states only what a group's setup is, what a test may or may not do to belong there, and the ordering constraint about `base`. The explanation of the `isBranchModified()` cache is gone too, since that test now runs with a fresh `initRepo()` in the reused-clone group. Comments only, no test changes. Co-Authored-By: Claude Fable 5.1 <michael.kriese+claude-code@mend.io> * test(util/git): move isBranchModified() into the shared-clone group `isBranchModified()` only reads the repository, but it stores results in `config.branchIsModified`, which only `initRepo()` cleared. That kept its 16 tests in the reused-clone group at about 0.35s each. A new `clearBranchIsModifiedCache()` helper, marked `@internal`, clears that store. The shared-clone `beforeEach` calls it along with the cheap config setters (`setUserRepoConfig`, `setGitAuthor`, `setPlatformIgnoredAuthors`), so those tests now share one `initRepo()` and cost a few milliseconds each. The file drops from about 87s to about 83s. A dynamic import with `vi.resetModules()` was considered instead: a fresh module instance has no `config` and `gitInitialized = false`, so every test would need its own `initRepo()` and `syncGit()` on it, which is the reused-clone cost again plus re-importing the module graph. Co-Authored-By: Claude Fable 5.1 <michael.kriese+claude-code@mend.io> --------- Co-authored-by: Claude Fable 5.1 <michael.kriese+claude-code@mend.io>
What is the Mend Renovate CLI?
Renovate is an automated dependency update tool. It helps to update dependencies in your code without needing to do it manually. When Renovate runs on your repo, it looks for references to dependencies (both public and private) and, if there are newer versions available, Renovate can create pull requests to update your versions automatically.
Features
- Delivers update PRs directly to your repo
- Relevant package files are discovered automatically
- Pull Requests automatically generated in your repo
- Provides useful information to help you decide which updates to accept (age, adoption, pass rates, merge confidence)
- Highly configurable and flexible to fit in with your needs and repository standards
- Largest collection of languages and platforms (listed below)
- Connects with private repositories and package registries
Languages
Renovate can provide updates for most popular languages, platforms, and registries including: npm, Java, Python, .NET, Scala, Ruby, Go, Docker and more. Supports over 90 different package managers.
Platforms
Renovate updates code repositories on the following platforms: GitHub, GitLab, Bitbucket, Azure DevOps, AWS Code Commit (experimental), Gitea, Forgejo, Gerrit (experimental), SCM-Manager (experimental)
Ways to run Renovate
The most effective way to run Renovate is to use an automated job scheduling system that regularly runs Renovate on all enabled repositories and responds with priority to user activity. Mend offers cloud-hosted and self-hosted solutions. See the options below.
Mend Renovate Community (Cloud-Hosted)
Supports: GitHub.com, Bitbucket Cloud
Hosted by Mend.io. No setup is needed. Community plan available (Free)
- GitHub Cloud: Install the Renovate Cloud-Hosted App on your GitHub org, then select the repos to enable
- Bitbucket Cloud: Add the Mend App to your Workspace, then add the Mend Renovate user to the projects you want to enable
Mend Renovate Community (Self-hosted)
Supports: GitHub, GitLab, Bitbucket Data Center
Install and run your own Renovate server. Access internal packages.
- Mend Renovate Community Self-Hosted (Free)
- Mend Renovate Enterprise (Paid plan)
Other ways to run Renovate
If you can’t use a pre-built job scheduling system, or want to build your own, the following options are available:
Run Renovate on your Pipeline
Mend provides a GitHub Action or a GitLab Runner to help you run Renovate as a CI pipeline job.
- GitHub Action: renovatebot/github-action.
- GitLab Runner: Renovate Runner project
- AzureDevOps action: Renovate Me extension
Note: This extension is created and maintained personally by a Renovate developer/user. Support requests for the extension will not be answered directly in the main Renovate repository. - Custom pipeline: You can create a custom pipeline with a yml definition that triggers npx renovate. More details on how to configure the pipeline.
Run Renovate CLI
There are several ways to run the Renovate CLI directly. See docs: Running Renovate for all options.
Supports: all platforms
For additional community-maintained options, see the Community Tools page.
Docs
More about Renovate
- Renovate basics
- Supported platforms and languages
- Advanced Renovate usage
Renovate Docs
Comparisons
Get involved
Issues and Discussions
Please open a Discussion to get help, suggest a new feature, or to report a bug. We only want maintainers to open Issues.
Contributing
To contribute to Renovate, or run a local copy, please read the contributing guidelines.
- Guidelines for Contributing
- Items that need contribution: good first issues
Contact and Social Media
The Renovate project is proudly supported and actively maintained by Mend.io.
- Contact Mend.io for commercial support questions.
Follow us on:
- Twitter: x.com/mend_io
- LinkedIn: linkedin.com/company/mend-io
Security / Disclosure
If you find any bug with Renovate that may be a security problem, please report it through the GitHub Security Advisories process. This way we can evaluate the bug and hopefully fix it before it gets abused. Please give us enough time to investigate the bug before you report it anywhere else.
If you would like to discuss a potential finding before raising the Advisory, then e-mail us at: renovate-disclosure@mend.io.