Dependency Updates

Renovate checks this repo's pinned dependencies once a week and opens PRs for the ones that are behind. It runs as the renovate-bot Gitea user from .gitea/workflows/renovate.yml, and its config is renovate.json5.

Everything it finds, including updates it is holding back, is listed on the Dependency Dashboard issue, which is pinned on the issue tracker.

Third Party Dependencies is the record of what is deployed; this page covers what keeps it current.

What it manages

Source	Where	Label
Actions used by Gitea workflows, and the Python version they give actions/setup-python	.gitea/workflows/*.yml, .gitea/actions/*/action.yml	ci/cd
glualint	.gitea/scripts/glualint-version	ci/cd
lua-language-server	tools/docs/luals-version	ci/cd
GLuaTest image	GLUATEST_IMAGE default in .gitea/scripts/gluatest.sh	ci/cd
Test database image (mariadb)	GLUATEST_DB_IMAGE default in .gitea/scripts/gluatest-db.sh	ci/cd
Client E2E image (ubuntu)	E2E_IMAGE default in .gitea/scripts/client-e2e-docker.sh	ci/cd
Electron (the E2E run's chrome-sandbox)	E2E_ELECTRON_VERSION default in .gitea/scripts/client-e2e.sh	ci/cd
Renovate itself	RENOVATE_IMAGE in .gitea/workflows/renovate.yml	ci/cd
Photon's linter library (EMVU siren and component lint)	LINTER_LIBRARY_VERSION in .gitea/workflows/ci.emvu.yml	ci/cd
Python requirements	tools/docs/requirements.txt, tools/docs-mcp/requirements.txt	dependencies
docs-mcp base image	tools/docs-mcp/Dockerfile	dependencies
Git submodules	addons/photon, tools/docs/vendor/glua-api-snippets	dependencies

The scripts' defaults are found by the custom managers in renovate.json5, which match the ${VAR:-image:tag} shape. Renaming one of those variables, or moving a pin to a new file, needs the matching manager updated in the same change or Renovate silently stops seeing it.

Held back on purpose

• GLuaTest image. The harness refuses any GLuaTest build it has no checksum for, and the version is repeated in the sweep's tests, cityrp_suites.lua, CONTRIBUTING and ADR 0002. A new release only appears on the Dashboard. Ticking it there makes Renovate open a PR that changes gluatest.sh alone, so only tick it if you are going to finish the bump on that branch.
• actions/upload-artifact and actions/download-artifact stay below v4, which fails on Gitea with GHESNotSupportedError.
• mariadb stays on the 12.x line, the major Live runs. Move the rule in renovate.json5 when Live moves.

What it leaves alone

Not managed	Why
.github/**	A stale mirror of the GitHub-era workflows, which never run on Gitea
Vendored addons in addons/	Heavily forked; an upstream change is merged by hand. Third Party Dependencies records the upstream of each
Binary modules	Live in cityrp2-cfg, and each is a checked build, not a version bump
libffi7 in install-glualint	A fixed Ubuntu archive .deb that glualint links against, with nothing newer to move to
steamcmd and the Steam client	Only ever published as latest
The docs-mcp image in docker-compose.yml	This repo builds it

How PRs are paced

Every PR runs the full GLuaTest suite on a runner that shares Gitea's disk, so the config keeps the number of pushes down:

• Grouped. Non-major updates arrive as one PR per group: GitHub Actions, Python requirements and tool pins (the version files, script images, Electron, Renovate, the linter library and the Dockerfile's base image). Each major update and each submodule gets its own PR.
• At most five open at once.
• Rebased only on conflict. An open Renovate PR is not rebased every time master moves, so it does not rerun CI for nothing. A stale one still merges.
• Titles and commits are chore(deps): …, so no Renovate PR ever carries a public= changelog entry.

Merging

Master's protection applies as usual: three green checks and one approval. Non-major updates have auto-merge set, so they merge as soon as someone approves them. Majors and submodules are merged by hand.

Renovate branches start renovate/, which triggers no deploy workflow. The exception is Photon, the only update that changes game Lua: its branch starts dev/renovate/, so it can be put on a development server with !branch before it is approved.

Submodules and feature branches

Renovate bumps each submodule to the head of the branch .gitmodules names for it:

• addons/photon tracks development.
• tools/docs/vendor/glua-api-snippets tracks lua-language-server-addon.

While a Photon feature is being tested ahead of development, point Photon's branch = in .gitmodules at that feature branch alongside the gitlink. Otherwise Renovate reads the pinned commit as behind development and opens a PR moving it back. Set it back to development once the feature has merged upstream.

Running it

The workflow runs every Monday at 05:00 UTC. To run it by hand, open Actions → Renovate → Run workflow. It takes two inputs:

• dry_run: off opens and updates PRs; lookup logs the updates it would make and writes nothing; full also logs the branches it would push.
• log_level: info, or debug to see every extracted dependency.

A PR that touches renovate.json5 or the workflow runs the config through renovate-config-validator --strict.

To see what Renovate would find without touching Gitea, run the image against a checkout with the local platform. The checkout needs a normal .git directory; a worktree's .git file points at a path the container cannot see.

docker run --rm -v "$PWD:/usr/src/app" -w /usr/src/app -e LOG_LEVEL=debug ghcr.io/renovatebot/renovate:44.112.3 renovate --platform=local

The Dependency Dashboard and triage

The Dashboard carries no type/ or status/ label, so buckets.sh leaves issues filed by renovate-bot out of the unlabelled bucket. It is not a ticket, and giving it status/triaged instead would list it as work ready to pick up.

Setup

These are one-off steps for an instance admin. They were done when Renovate was added, and are only needed again if the bot or its tokens are replaced.

1. Create a Gitea user renovate-bot, and give it Write access to limelight-development/cityrp2. Auto-merge merges as the bot, so if master's protection ever gains a merge whitelist, the bot needs adding to it.
2. As renovate-bot, create an application token with read:user, write:issue, write:repository and read:organization. Save it as the repo Actions secret RENOVATE_TOKEN.
3. Create a github.com token with read-only access to public repositories and no other scopes (a classic token with no scopes ticked is enough). Save it as RENOVATE_GITHUB_COM_TOKEN. Without it, GitHub rate-limits the release lookups, and Renovate skips every action and GitHub-hosted tool. Gitea reserves secret names starting GITHUB_, hence the prefix.
4. Run the workflow by hand with dry_run: lookup and check the log. Then run it with off, and pin the Dependency Dashboard issue it creates.

The workflow fails straight away, naming the missing secret, if either is unset.