Development: Use an internal Maven Central mirror to prevent dependency rate-limit errors in CI

[krusche]

Summary

Builds and server tests resolve their Gradle dependencies directly from Maven Central. Because many CI jobs run concurrently behind a shared egress IP, this regularly triggers HTTP 429 Too Many Requests responses from Maven Central — and due to Gradle's blacklist-on-error behavior, a single 429 fails the whole build. This PR routes dependency resolution through the internal TUM AET Reposilite mirror (which proxies Maven Central and has no per-IP rate limit) as the preferred repository, and unifies the GitHub Actions Gradle dependency cache onto setup-gradle.

Checklist

General

• This is a small, infrastructure-only change (Gradle build configuration + CI workflows, no application code) that I verified locally (Gradle offline configuration check + YAML validation) and via the CI pipeline on this PR.
• Language: I followed the guidelines for inclusive, diversity-sensitive, and appreciative language.
• I chose a title conforming to the naming conventions for pull requests.

Motivation and Context

CI experienced repeated Maven Central 429 Too Many Requests errors during dependency resolution. With many build/test jobs running concurrently behind a shared egress IP (the self-hosted aet-large-ubuntu runners in particular), the aggregate request volume crosses Maven Central's per-IP rate limit. Gradle (4.3+) does not fall through to the next repository on an HTTP error — it blacklists the repository and fails the build — so a single 429 aborts the job.

The TUM AET Reposilite instance proxies Maven Central from inside our own infrastructure and is not subject to a per-IP rate limit, so making it the preferred repository removes the root cause.

Description

Gradle — preferred mirror (with mavenCentral() kept as a fallback), added first in all three repository declaration sites:

• settings.gradle → pluginManagement.repositories (plugin + root buildscript classpath resolution)
• build.gradle → top-level repositories (project / server dependencies)
• gradle/openapi.gradle → buildscript.repositories (openapi-generator)

The mirror (https://reposilite.aet.cit.tum.de/releases) is listed first; mavenCentral() remains as a fallback, and the existing Spring-milestone / Gradle / Shibboleth repos and gradlePluginPortal() are kept for artifacts the mirror does not proxy.

GitHub Actions — Gradle caching via setup-gradle:

• Standardized every server build/test workflow on gradle/actions/setup-gradle@v6 as the sole Gradle dependency-cache mechanism, removing the redundant cache: 'gradle' from setup-java where present (the two would otherwise contend for ~/.gradle).
• setup-gradle prunes unused artifacts before saving, keeping cache entries lean — this reduces GitHub Actions cache eviction (10 GB/repo, LRU) and the dependency re-downloads it causes.
• Added Gradle caching to ci-bean-instantiations.yml, which previously had none (full fresh download on every run).
• All setup-gradle references use the floating @v6 tag and are kept consistent across: ci-build.yml, ci-test.yml, ci-quality.yml, ci-codeql.yml, ci-bean-instantiations.yml, nightly-lti-interop.yml, test-mysql.yml. (gradle/actions/wrapper-validation remains SHA-pinned.)

Resilience note: if the mirror is ever unreachable, the mavenCentral() fallback only reliably rescues the build when the host is fully DNS-unresolvable. On an HTTP 5xx/429 or connection timeout from the mirror, Gradle blacklists it and fails (the same behavior we have today with Maven Central). The mirror's own availability therefore matters; a warm Gradle cache (~/.gradle/caches) remains the primary protection for transient outages.

Steps for Testing

This change is verified by CI itself rather than by manual feature testing:

1. Confirm all CI checks on this PR pass (Build, Test, CodeQL).
2. In a CI job log (e.g. the ci-build WAR build), confirm dependency/plugin artifacts are fetched from reposilite.aet.cit.tum.de rather than repo1.maven.org.
3. Confirm the Setup Gradle step reports a Gradle cache restore/save in each migrated workflow.

Testserver States

You can manage test servers using Helios. Check environment statuses in the environment list. To deploy to a test server, go to the CI/CD page, find your PR or branch, and trigger the deployment.

Review Progress

Code Review

• Code Review 1
• Code Review 2

[coderabbitai]

Walkthrough

Adds a TUM-hosted reposilite Maven Central mirror (https://reposilite.aet.cit.tum.de/releases) as a named repository (reposiliteRepository) in three Gradle build files: the root build.gradle dependency repositories block, gradle/openapi.gradle buildscript repositories, and settings.gradle plugin management repositories.

Changes

Reposilite Maven Mirror Configuration

Layer / File(s)	Summary
Add reposilite mirror to all Gradle repository blocks settings.gradle, gradle/openapi.gradle, build.gradle	Registers reposiliteRepository pointing to https://reposilite.aet.cit.tum.de/releases in pluginManagement.repositories, buildscript.repositories, and the main repositories block respectively.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: adding an internal Maven Central mirror to prevent rate-limit errors in CI builds, which aligns with the core objective of the pull request.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch chore/maven-central-mirror

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Copilot]

Pull request overview

This PR improves CI reliability by preferring an internal TUM AET Reposilite proxy for Maven Central (to avoid upstream 429 rate limiting) and by consolidating Gradle dependency caching in GitHub Actions onto gradle/actions/setup-gradle@v6.

Changes:

• Added the internal Reposilite Maven Central mirror as the first Gradle repository for plugin resolution, build dependencies, and the OpenAPI buildscript.
• Replaced actions/setup-java’s Gradle caching with gradle/actions/setup-gradle@v6 across the affected CI workflows to avoid cache contention and keep caches leaner.
• Added Gradle caching to workflows that previously lacked it (e.g., bean instantiation checks).

Reviewed changes

Copilot reviewed 8 out of 9 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
settings.gradle	Prefer internal Reposilite mirror for Gradle plugin resolution, keeping Maven Central as fallback.
gradle/openapi.gradle	Prefer internal Reposilite mirror for OpenAPI buildscript dependencies.
build.gradle	Prefer internal Reposilite mirror for project dependency resolution.
.github/workflows/test.yml	Use setup-gradle@v6 as the sole Gradle caching mechanism for server test/style jobs.
.github/workflows/test-mysql.yml	Use setup-gradle@v6 as the sole Gradle caching mechanism for MySQL server tests.
.github/workflows/nightly-lti-interop.yml	Add setup-gradle@v6 caching to the nightly LTI interop job.
.github/workflows/codeql-analysis.yml	Add setup-gradle@v6 caching before the Gradle build used for CodeQL.
.github/workflows/build.yml	Remove setup-java Gradle cache usage and standardize on setup-gradle@v6.
.github/workflows/bean-instantiations.yml	Add setup-gradle@v6 caching to the bean instantiation workflow.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[bensofficial]

Changes look good

[github-actions]

End-to-End Test Results

Phase	Status	Details
All Tests	❌ Failed	Tests Passed ☑️ Skipped ⚠️ Failed ❌️ Time ⏱ All E2E Tests Report (PR) 278 ran 273 passed 3 skipped 2 failed 48m 33s

❌ Failed Tests

• Group chat messages › Write/edit/delete message in group chat › Student should be able to edit a message in group chat (1m 29s)
• Message interactions › Message forwarding › Forwarded reply renders its preview in the destination conversation (1m 28s)

Flakiness Scores for Failed Tests

Test	Flakiness Score	Default Branch Failure Rate	Combined Failure Rate
e2e/course/CourseGroupChatMessages.spec.ts#Group chat messages › Write/edit/delete message in group chat › Student should be able to edit a message in group chat	0%	0.3%	0.3%
e2e/course/CourseMessageInteractions.spec.ts#Message interactions › Message forwarding › Forwarded reply renders its preview in the destination conversation	0%	50.9%	50.9%

Test Strategy: Running all tests (configuration or infrastructure changes detected)

Overall: ❌ E2E tests failed

🔗 Workflow Run · 📊 Test Report

[FelixTJDietrich]

Changes look good to me, Claude Opus 4.8 usually insists on pinning workflows to follow best practices. AFAIK you can also make this compatible with renovate / other dependency automations, if it is not already. But using a major version with trusted workflows should usually be fine, especially on GitHub runners.