mirror of
https://github.com/Stirling-Tools/Stirling-PDF.git
synced 2026-09-03 05:10:16 +03:00
Anthony Stirling
28480d137a
# 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.
Stirling PDF - The Open-Source PDF Platform
Stirling PDF is a powerful, open-source PDF editing platform. Run it as a personal desktop app, in the browser, or deploy it on your own servers with a private API. Edit, sign, redact, convert, and automate PDFs without sending documents to external services.
Key Capabilities
- Everywhere you work - Desktop client, browser UI, and self-hosted server with a private API.
- 50+ PDF tools - Edit, merge, split, sign, redact, convert, OCR, compress, and more.
- Automation & workflows - No-code pipelines direct in UI with APIs to process millions of PDFs.
- Enterprise‑grade - SSO, auditing, and flexible on‑prem deployments.
- Developer platform - REST APIs available for nearly all tools to integrate into your existing systems.
- Global UI - Interface available in 40+ languages.
For a full feature list, see the docs: https://docs.stirlingpdf.com
Quick Start
docker run -p 8080:8080 docker.stirlingpdf.com/stirlingtools/stirling-pdf
Then open: http://localhost:8080
For full installation options (including desktop and Kubernetes), see our Documentation Guide.
Resources
Support
- Community: Discord
- Bug Reports: GitHub Issues
Contributing
We welcome contributions! Please see CONTRIBUTING.md for guidelines.
This project uses Task as a unified command runner for all build, dev, and test commands. Run task dev to get started running the editor, run task to see the most common commands, or see the Developer Guide for full details.
For adding translations, see the Translation Guide.
License
Stirling PDF is open-core. See LICENSE for details.