Mend Renovate Self-hosted Apps (Community Edition and Enterprise Edition) are commercial offerings of Renovate for self-hosted users, such as those running on GitHub, GitLab or Bitbucket Data Center.
Essentially, it is an alternative to running the renovate CLI tool, with the following additions:
- Stateful job queue for prioritization of job importance
- Embedded job scheduler to remove the need to set up and monitor
cron - Webhook listener to enable dynamic reactions to repository events
- Administration APIs for probing the system state or triggering jobs
The Docker containers for Mend Renovate Self-hosted App contain a built-in job scheduler that defaults to enqueing all repositories once per hour.
This saves the need for configuring and monitoring any external cron process.
Mend Renovate Self-hosted App also supports a webserver to listen for system webhooks received from the SCM (GitHub, GitLab, Bitbucket).
In particular, it checks webhooks for:
- Projects it has just been added to
- Commits to
mainbranch that touch "important" files:- Renovate's configuration filenames (e.g.
renovate.json) - any known package manager files, as found by the
managerFilePatternsin each package manager's default configuration, e.g. thebazelmanager's default config
- Renovate's configuration filenames (e.g.
- Any commits made to Renovate's branches
- Closing or merging of Renovate PRs
Each of the above results in a job being enqueued for the relevant repository, so that the bot will appear responsive to users.
Priority-based queuing is essential for providing a responsive experience for bot users. For example, if a user makes an update to the config in an onboarding PR, they ideally want to see the results immediately. By assigning onboarding updates the highest priority in the queue, the bot's update to the onboarding PR can proceed as the very next job, even if many others were in the queue already.
In general, job priority is based on the probability that a user may be "waiting" for the bot to do something. That's why onboarding updates are highest priority, and other high priority updates include merging of Renovate PRs because that very often results in other PRs needing updates or rebasing afterwards.
Logically, Mend Renovate consists of four components:
- In-memory DB/state
- Used for storing the job queue and a list of known installations and repositories
- Can be persisted to file and interrogated by SQL tools
- Scheduler
- Runs according to a
cronschedule (defaults to hourly) - Retrieves a list of all installed repositories and adds them to the job queue
- Runs according to a
- Webhook Handler
- Listens for webhook events from GitHub/GitLab, on path
/webhook - Adds high priority jobs to the job queue if event conditions are met (e.g. a merged or closed Renovate PR, an update to an existing Renovate PR, a commit to
renovate.jsoninmainbranch, etc)
- Listens for webhook events from GitHub/GitLab, on path
- Worker
- A wrapper on Renovate CLI, it runs non-stop, retrieving the highest priority job (repository) from the queue one at a time
All four components run within a shared container. As with Renovate CLI, it can also be configured to interact with an external Redis server as an alternative to the default disk-based cache.
The Docker images for Mend Renovate Self-hosted App are available via GitHub Container Registry (ghcr.io)
Use of the images are in accordance with the Mend Terms of Service.
-
Community Edition: mend/renovate-ce.
-
Enterprise Edition: Enterprise Edition uses two separate Docker images: The Server image, and the Worker image.
- Server image: mend/renovate-ee-server
- Worker image: mend/renovate-ee-worker
Mend Renovate Self-hosted Apps have their own versioning and release schedule, independent of Renovate CLI versioning.
Additionally, it is intended that Mend Renovate Self-hosted Apps will have a slower release cadence than Renovate CLI in order to provide greater stability for Enterprise use.
Specifically, use of SemVer for Mend Renovate Self-hosted Apps:
Major: Used only for breaking changes
Minor: Used for feature additions and any bug fixes considered potentially unstable
Patch: Used only for bug fixes that are considered to be stabilizing
i.e. we do not want to ever "break" anyone with a patch release, or have behavior change.
Renovate CLI feature releases (i.e. minor version bumps in Renovate CLI) will therefore only be incorporated into minor releases of Mend Renovate.
Typically, multiple Renovate CLI feature releases will be rolled up into a single Mend Renovate release, and release notes will be embedded so that you do not need to look them up separately.
The release cadence of Mend Renovate is not fixed, as it will be determined largely by the importance and stability of new Renovate CLI features, which will typically be tested using the hosted Renovate GitHub App first.
When a new version of Mend Renovate is pushed to GHCR, Release Notes will be added to this github.com/mend/renovate-ce-ee repository.
Naturally, it is recommended that you use Renovate itself for detecting and updating Mend Renovate versions if you are using a Docker Compose file internally for running Mend Renovate.
See the Setup Guides to get started with Mend Renovate Self-hosted App
Examples using Docker Compose can be found at in the examples directory.
Request /health on your IP address hosting the deployment to check if it is running correctly.
For further testing, use the Admin APIs to:
- check the status of the server
- see the contents of the Job and Task queues
- perform an App sync
- run a job
It is recommended not to expose the API endpoint to the internet as it could leak information about private repository names.