Sebastian Poxhofer
44160755f9
* refactor(platform): share one implementation between gitea and forgejo The `forgejo` platform was copied from `gitea` in #37075 and the two have drifted since: fixes landed on one side only (zod validation #43900, empty email #44068, null issues #44048, team reviewers #39533, merge-style fallback #37768 vs #38040), and lint sweeps had to be applied to both copies by hand. Both platforms now build on `lib/modules/platform/gitea-common/`, which holds the zod schemas, API helpers, utils, PR cache and the platform object itself. `createPlatform()` closes over its own state, so `gitea` and `forgejo` keep separate config, caches and host types. `gitea/index.ts` and `forgejo/index.ts` are thin wrappers that supply the platform id, default endpoint, http client and the version gates that genuinely differ. Reconciliations, forgejo's behaviour adopted for gitea: - Responses are validated with zod instead of `getJsonUnchecked` casts. Gitea therefore tolerates empty emails, null PRs in list responses and lenient repo/issue payloads the same way Forgejo already did. - `getRepoContents` returns a discriminated union, so `getRawFile` returns null for dir/symlink/submodule entries instead of reading a missing field. The gitea preset resolver now throws PRESET_INVALID for non-file entries, like the forgejo one. - An unknown `default_merge_style` (e.g. `manually-merged`) is caught by the schema and skipped, instead of aborting the repository with REPOSITORY_BLOCKED from `isAllowed()`. - `initRepo()` resolves whether the repo owner is an org and only fetches org labels when it is, adding one `/orgs/{owner}` request and an `orgs` entry in the gitea repository cache. - Reviewers prefixed with `team:` are sent as `team_reviewers`. Gitea keeps its `v1.14.0` guard for requesting reviewers at all. - `getBranchStatusCheck()` maps unknown commit status values through the schema's `unknown` fallback rather than warning and returning yellow. Gitea's behaviour is kept where it is deliberately different: the Forgejo instance detection and its deprecation notice, the `1.24.0` (or `10.0.0` for a detected Forgejo) native automerge gate, and the reviewer version guard are passed in as options. Two shared log messages became static so they can be grouped in metrics: `{platform}-native automerge: fail` is now `Platform-native automerge: fail` and `{Platform} getRepos() error` is now `Error auto-discovering repositories`, both with the platform id in the metadata. The dead `defaults.hostType` field is gone. * refactor(platform): keep the shared gitea implementation under gitea/ Drop the `gitea-common/` folder. The zod schemas, API helpers, utils, PR cache and `createPlatform()` live in `lib/modules/platform/gitea/` under their original file names, and `forgejo/` imports them from there. The preset resolvers pass `giteaHttp` and `forgejoHttp` to `getRepoContents()` directly, which removes the two bound wrappers. The gitea changelog source uses the shared `RepoContents` type like the forgejo one already does. * refactor(http): derive ForgejoHttp from GiteaHttp The two clients were identical apart from the default `hostType`. `ForgejoHttp` now extends `GiteaHttp` and only keeps its own base url, so the pagination logic exists once. The platform helpers accept `GiteaHttp` directly instead of the `HttpBase` alias. Also covers the `updatePr()` branch where the updated pull request cannot be converted and therefore is not cached. * refactor(platform): create the gitea and forgejo http clients in index.ts `forgejo-helper.ts` only held the `ForgejoHttp` instance, so it is gone and `forgejo/index.ts` creates the client next to the platform. Gitea does the same for symmetry, which leaves `gitea-helper.ts` with only the shared API helpers. * refactor(platform): fetch gitea labels and issues with await `getLabelList()` and `getIssueList()` still memoize the in-flight promise, but build it from small async functions instead of `.then()` and `.catch()` chains. * refactor(platform): keep declaration order of gitea/index.ts Order the module the way it was before `createPlatform()` so the diff against main aligns: platform id and http client after the repo config interface, pure helpers before the factory, and `maxBodyLength()` after the platform object. * refactor(platform): move gitea label fetching to labels.ts `fetchLabelList()` takes the http client and the repository details instead of closing over the platform state, and gets its own spec. The factory only keeps the memoizing `getLabelList()`. * refactor(platform): move gitea label lookup to labels.ts * refactor(platform): create the gitea pr cache per platform `GiteaPrCache` is now created once per platform with its http client and platform id, and `initRepo()` records the repository. The per-repository state moves to a private `RepoPrCache` which is bound to the repository cache on first use and reused until the next `initRepo()`, instead of being rebuilt on every lookup.
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.