build: prepare for Renovate and add a dependency cooling-off period

[feanil]

Groundwork for moving dependency management to Renovate. The Renovate config
itself is a small follow-up PR; this one is everything that has to be true
first, plus adjacent breakage found along the way.

Why

The repo has two dependency-update mechanisms and neither works. The weekly
Upgrade Python Requirements workflow calls the shared openedx pip-tools
workflow, which runs make upgrade from the repository root — there is no root
Makefile, and its ADD_PATHS="requirements" would never stage uv.lock. It
has failed every run since the move to uv. Renovate was intended for the Node
side but was never configured. Dependabot covers github-actions only, so
neither package-lock.json has ever been updated.

The cooling-off period

The headline change is a 7-day minimum release age on every dependency, so a
freshly published — possibly hijacked — release cannot be pulled in
immediately.

It is configured in the package managers, not in Renovate, because
Renovate cannot enforce a cooldown on a lockfile refresh: it delegates that to
uv or npm and never enumerates the individual releases, so
minimumReleaseAge does not apply to it. Configuring the resolvers instead
covers transitive dependencies as well as direct ones, and means make upgrade
or npm install on a laptop behaves exactly like the bot will.

Where	Setting
backend-plugin-sample/pyproject.toml	[tool.uv] exclude-newer = "7 days"
frontend-plugin-sample/.npmrc, brand-sample/.npmrc	min-release-age=7
renovate.json5 (next PR)	minimumReleaseAge: '7 days'

These three have to stay in agreement. If the resolvers are stricter than
Renovate, Renovate proposes versions they refuse and leaves empty branches
behind.

Verified that this does not disturb the install path: uv lock is idempotent
afterwards, uv lock --check and uv sync --locked still pass, and npm ci
plus npm run build are unaffected in both npm packages.

Why >=0 on every dependency

Renovate drops any PEP 621 dependency with no version specifier at all
(skipReason: "unspecified-version") before it ever queries PyPI — a correct
lockedVersion in uv.lock does not help, because the manifest is what it
reads as the reference. Almost every entry here was a bare name, so Renovate
would have produced no update PRs for them.

>=0 is the PEP 440 equivalent of the "*" ranges already used in
frontend-plugin-sample/package.json; PEP 440 has no bare wildcard, as
Django==* is a parse error. It keeps these deliberately unconstrained — the
platform pins them itself, and a plugin that narrows them causes resolution
conflicts inside edx-platform — while stating that intent explicitly instead
of leaving it implied by omission.

Real floors were considered and rejected: derived from uv.lock they would be
guesses, since the lock records the newest resolvable version rather than the
oldest supported one. Django>=5.2 would block installation on a platform
running Django 4.2, quite possibly wrongly.

The one genuine floor is edx-lint>=6.2, which is verifiable rather than
guessed — see below.

One required status check instead of six

Branch protection matches required checks by name, which made the required list
both fragile and incomplete.

Fragile, because naming the backend jobs individually means spelling out every
matrix leg — tests (ubuntu-latest, 3.12, django52) and four more — so adding
or retiring a Python or Django version quietly breaks protection until someone
updates the repository settings.

Incomplete, because the frontend and tutor jobs were both called build.
Two check runs with one name cannot be told apart in a required list, so
neither was ever required. A pull request touching nothing but frontend files
could merge on the strength of checks that could not have been affected by it.
That gap matters much more once dependency updates start merging themselves,
because GitHub's auto-merge waits for required checks and nothing else.

So ci.yml now runs on pull requests, invokes each per-package workflow, and
ends in a gate job that succeeds only if all of them did. gate is the only
name branch protection has to know, and it never changes. release.yml calls
ci.yml too, so a release runs exactly the checks that were required to merge.

The aggregation is five lines of shell rather than a third-party action. This
job is the one thing standing between a pull request and main, so it is the
last place worth adding a dependency — particularly in a change whose purpose
is to reduce how much unreviewed third-party code we pull in.

Things this turned up

make upgrade was broken. It calls edx_lint write_uv_constraints, which
does not exist before edx-lint 6.2.0 — with edx-lint pinned at 6.0.0 the target
printed the usage text instead of regenerating anything. Raising the floor
surfaced two files edx-lint owns that had drifted: constraint-dependencies was
missing three of edx-lint's global constraints, and pylintrc was still stamped
Generated by edx-lint version: 5.6.0, predating the plugin's requirement that
pii_terms be configured — under 6.2.0 pylint aborted outright.

make check-constraints now guards that, wired into the quality toxenv. The
loop closes itself: edx-lint is a managed dependency, so the pull request that
bumps it is the one that goes red if its global constraints moved along with it.
This is the alternative to a scheduled regeneration job, which Renovate cannot
do (the hosted app has no postUpgradeTasks) and which would anyway produce
pull requests that do not trigger CI when using the default GITHUB_TOKEN.

brand-sample had no CI, and it is publishing. Its dist/ is committed and
served to real MFEs straight from GitHub via
cdn.jsdelivr.net/gh/openedx/sample-plugin@main, so it is a published artifact
rather than a build leftover. Bumping package-lock.json does not regenerate
it, so a dependency update could quietly leave the CSS people download out of
step with the sources here. The new job rebuilds and diffs dist/. Its .nvmrc
also moves from Node 20 to 24 — Node 20 is EOL and bundles npm 10.8.2, which
silently ignores min-release-age, so brand-sample would have got no benefit
from the cooldown at all.

Two runtime dependencies were undeclared. apps.py imports
edx_django_utils and pipeline.py imports crum, but neither was in
[project].dependencies. They resolved anyway because the test-base group
pulls in edx-django-utils, which brings django-crum transitively — so the
omission was invisible in development and in CI, and would only surface as an
ImportError for someone installing the published wheel.

.readthedocs.yaml is dormant, not broken. It did ask for the deleted
requirements/doc.txt, but Read the Docs reads its config from the repository
root and this file is a directory down, so nothing reads it — and no project
exists (both plausible subdomains 404). Fixed in place using Read the Docs'
native method: uv support so it resolves from uv.lock, with a note
recording that it is dormant and that its paths are relative to
backend-plugin-sample/. Docs are built with fail_on_warning on every pull
request by tox -e docs regardless.

Merging this

The five tests (...) contexts stop reporting once backend-ci.yml no longer
runs directly on pull_request, so this PR cannot satisfy the current required
checks:

1. Set the required checks on main to just openedx/cla.
2. Merge.
3. Set them to openedx/cla, gate, and commitlint / commitlint.

commitlint.yml is deliberately left alone — it is one of the openedx standard
workflow files kept in sync by org automation, so folding it into ci.yml would
be reverted. Its context name does not depend on a matrix, so requiring it
separately costs nothing.

Merging cuts a patch release (fix: and build: commits are in patch_tags).

Not included

• frontend-plugin-sample/package.json is untouched. "*" is already a valid
  semver range, so Renovate sees those four dependencies today — "*" is the
  npm form of >=0. Changing them would mean inventing constraints.
• docs/openedx_plugin_sample.rst is stale — admin.py was added without
  regenerating the API docs, and tox -e docs refreshes it in place. Left out
  because docs: would bump this from a patch to a minor release. Worth a
  follow-up.
• The two test toxenvs segfault locally, identically on an unmodified checkout
  of main, so it is a local environment problem rather than anything here.
  CI on main is green and pytest run directly passes all 23 tests.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.04%. Comparing base (1f6766e) to head (60299da).

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #67   +/-   ##
=======================================
  Coverage   93.04%   93.04%           
=======================================
  Files          16       16           
  Lines         503      503           
  Branches       18       18           
=======================================
  Hits          468      468           
  Misses         24       24           
  Partials       11       11           

Flag	Coverage Δ
unittests	93.04% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.