mirror of
https://github.com/Stirling-Tools/Stirling-PDF.git
synced 2026-09-03 05:10:16 +03:00
# Description of Changes Fixes the `playwright-e2e-live` failure seen on [run 30694073128](https://github.com/Stirling-Tools/Stirling-PDF/actions/runs/30694073128). The backend never started: ``` > Could not resolve org.springframework.boot:spring-boot-buildpack-platform:4.0.6. > Could not GET 'https://repo.maven.apache.org/maven2/.../spring-boot-buildpack-platform-4.0.6.pom'. Received status code 429 from server: Too Many Requests > There are 14 more failures with identical causes. BUILD FAILED in 21s ``` Gradle was throttled by Maven Central while resolving the buildscript classpath, `:stirling-pdf:bootRun` died, and the runner's "backend exited before becoming ready" guard aborted the suite before a single test ran. `e2e-live.yml` was the only Java-running workflow with no Gradle dependency cache, no `setup-gradle`, and no Maven mirror env - every sibling (`backend-build.yml`, `db-migration-test.yml`, `coverage-aggregate.yml`) has all three. So it downloaded the Gradle distribution and resolved the entire classpath cold from Maven Central on every single run, and eventually got throttled. Added: - the same `Cache Gradle dependency artifacts` + `Setup Gradle` pair used by `backend-build.yml` - `MAVEN_USER` / `MAVEN_PASSWORD` / `MAVEN_PUBLIC_URL` on the two Gradle-invoking steps, so runs that have the secrets use the internal mirror instead of hitting Central - a `Prime Gradle dependencies` step that retries 3x with backoff. Gradle does not retry 429s, and doing the cold resolve up front means a rate-limit failure retries cheaply instead of killing a backgrounded `bootRun` twenty minutes in Side benefit: the job gets faster once the cache is warm. ## Notes for reviewers - The 429 itself is transient infrastructure behaviour - a re-run would likely have gone green. The defect being fixed is that this job had no cache to fall back on, so it was exposed to it on every run. - `:stirling-pdf:classes` does not trigger a frontend build (`buildWithFrontend` defaults off, `app/core/build.gradle:147`), so priming before the Vite build step is safe. It is not wasted work either - `bootRun` compiles the same classes. - This PR originally also carried a fix for the `tauri-build` updater-key failure on that same run. #7181 fixes that more simply and has been merged, so that half has been dropped here. - Workflow changes cannot be fully verified locally; a CI run on this branch is the real check. --- ## Checklist ### General - [x] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [x] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [x] I have performed a self-review of my own code - [x] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [x] I have run `task check` to verify linters, typechecks, and tests pass - [x] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#7-testing) for more details.