Croway opened a new pull request, #1930: URL: https://github.com/apache/camel-spring-boot/pull/1930
Implements [CAMEL-24502](https://issues.apache.org/jira/browse/CAMEL-24502). Build infrastructure only, no shipped artifact is touched. ## 1. Least-privilege `permissions:` on the two scheduled workflows `.github/workflows/automatic-sync-main.yml` and `.github/workflows/generate-sbom-main.yml` declared no `permissions:` block, so their job ran with the repository default `GITHUB_TOKEN` grants. `pr-build-main.yml` and `pr-doc-validation.yml` already declare `permissions: contents: read`; this brings the remaining two workflows in line. Both now declare `permissions: {}` at the workflow level, and each job opts in to exactly what it needs. ## 2. Build split away from the PR-creation step Previously one job checked out and fully built `apache/camel`, then built camel-spring-boot, and then handed the write-capable token to `peter-evans/create-pull-request` — all in the same job. It is now two jobs: | job | grants | what it does | | --- | --- | --- | | `build` | `contents: read` | checks out `apache/camel` and camel-spring-boot, runs the same two `./mvnw` commands as before, uploads the regenerated changes as an artifact | | `create-pull-request` | `contents: write`, `pull-requests: write` | checks out camel-spring-boot, applies the artifact, calls `create-pull-request` | Cron schedule, the `if: github.repository == 'apache/camel-spring-boot'` guard, the `./mvnw` command lines, the `automatic-periodic-sync` branch name and the PR title/body text are all unchanged. Only the job structure and the grants change. ### Why a patch rather than a copy of the tree The handover artifact is a `git diff --cached --binary` patch, not a copy of the working tree: - **Size.** A typical periodic sync changes a handful of files (e.g. #1924 changed 4) out of a repository of well over a hundred thousand. Zipping and shipping the whole source tree twice a day to move four files would dominate the job runtime. - **Deletions.** A file overlay cannot express a deleted file. Regeneration does delete files when a component goes away, and those deletions would be silently dropped from the PR. Generation excludes the nested `apache/camel` checkout via the `':!camel'` pathspec; `target/` build output is already covered by `.gitignore`. The patch is applied with `git apply --3way`. The two jobs check out `main` at different times — potentially an hour or two apart, given the `apache/camel` build in between — so `--3way` merges an advanced `main` instead of failing on context drift. A genuine conflict fails the step loudly rather than producing a half-applied tree. `actions/download-artifact@v8` verifies the artifact digest and errors on mismatch by default, so the handover between the two jobs is integrity-checked. I verified the generate/apply round trip locally on a scratch repository covering: modified file, added text file, added binary file, deleted file, a nested git checkout named `camel`, gitignored `target/` output, and an unrelated commit landing on the destination branch between generation and application. All four changes came through, the nested checkout and build output were excluded, and the deletion was staged correctly. ### Action pinning Every `uses:` in these two workflows is pinned to a full commit SHA with the version as a trailing comment. SHAs were resolved with `gh api repos/<owner>/<repo>/git/ref/tags/<tag>`; all five refs are of type `commit` (no annotated tag objects needing dereferencing), so the pins are commits and not tag objects: ``` actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7 actions/setup-java@dd06d9cba3e5552c54d9f8ea23572deb30010f7c # v6 actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1 actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8.0.1 peter-evans/create-pull-request@5f6978faf089d4d20b00c7766989d076bb2fc7f1 # v8.1.1 ``` Anyone can re-run the same `gh api` calls to confirm. `.github/dependabot.yml` already has a `github-actions` ecosystem entry, so the pins will keep being bumped and the trailing comment updated — no change needed there. ## 3. Maven wrapper checksums `.mvn/wrapper/maven-wrapper.properties` gained `distributionSha256Sum` and `wrapperSha256Sum`, so `mvnw`/`mvnw.cmd` verify what they download instead of trusting the URL. Both values were computed from the artifacts at the exact URLs already in the file: ``` apache-maven-3.9.11-bin.zip sha256 0d7125e8c91097b36edb990ea5934e6c68b4440eef4ea96510a0f6815e7eeadb sha1 2b7fdf8f6983c7b295eab505b46825ee2d11959b == published .sha1 on repo.maven.apache.org sha512 03e2d65d...8207076 == published .sha512 on archive.apache.org maven-wrapper-3.3.4.jar sha256 4e2fbf6554bc8a4702cdfdd3bef464f423393d784ddbb037216320ce55d5e4e1 sha1 9a69c85449c23142f028e4566fa153e9fafe7a56 == published .sha1 on repo.maven.apache.org ``` So each value is corroborated by a checksum file published by the ASF alongside the artifact, and the distribution by a second one on an independent host. The wrapper jar sha256 also matches the `.mvn/wrapper/maven-wrapper.jar` already committed in this repository byte for byte, so the new property agrees with what contributors already run. Verified locally: - `./mvnw -v` still works with the existing wrapper cache (exit 0, Maven 3.9.11). - `./mvnw -v` with an isolated `MAVEN_USER_HOME` forces a fresh distribution download; it downloads, passes `distributionSha256Sum` and starts Maven 3.9.11. - Negative test with a deliberately wrong `wrapperSha256Sum`: `mvnw` aborts with *"Failed to validate Maven wrapper SHA-256"*. - Negative test with a deliberately wrong `distributionSha256Sum` and a clean wrapper home: the wrapper aborts with *"Failed to validate Maven distribution SHA-256"*. Both properties are therefore actually enforced by the wrapper version in use (3.3.4), not just cosmetic. ## Deferred - **Script-only wrapper mode.** The ticket mentions dropping the committed `maven-wrapper.jar` in favour of `distributionType=script` / the `only-script` wrapper. That changes how every contributor and every CI job bootstraps Maven and deserves its own PR and its own discussion, so it is intentionally not done here. With `wrapperSha256Sum` in place, the committed jar is now checksum-verified on every run, which covers the immediate concern. - **Pinning the other workflows.** `pr-build-main.yml`, `pr-doc-validation.yml` and `depsreview.yaml` still use floating tags. They are out of scope for this ticket and none of them combines a third-party build with a write-capable token; happy to follow up in a separate PR if reviewers want repo-wide consistency. ## Validation - `actionlint` 1.7.12 clean on both modified workflows. - All five workflow files and `.github/dependabot.yml` parse as YAML. - No Java or Maven module changed, so no test module applies. _Claude Code (Opus 5) on behalf of Federico Mariani_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_018uGVoZ1upWLheUxbE4XfVy -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
