HY-love-sleep opened a new issue, #7176:
URL: https://github.com/apache/shenyu/issues/7176
### Summary
`pr_build` in `ci.yml` builds only the changed modules plus their dependents:
```yaml
if [[ "${{ needs.changes.outputs.full_build_required }}" != "true" && -n
"${{ needs.changes.outputs.modules }}" ]]; then
MODULE_ARGS="-pl ${{ needs.changes.outputs.modules }} -am -amd"
fi
mvnd ${MAVEN_ARGS} ${MODULE_ARGS} test ${TEST_ARGS}
```
With `-amd`, a change in a plugin also pulls `shenyu-bootstrap` into the
reactor. `shenyu-bootstrap` depends on
most of the `shenyu-spring-boot-starter-*` modules, which are *not* part of
that reactor, so the build only
succeeds if they are already present in `~/.m2/repository` — that is, only
if the Actions cache was restored.
When the cache is missing, the job fails with a dependency-resolution error
that has nothing to do with the
change under test:
```
[ERROR] Failed to execute goal on project shenyu-bootstrap: Could not
resolve dependencies for project
org.apache.shenyu:shenyu-bootstrap:jar:2.7.2-SNAPSHOT
[ERROR] dependency:
org.apache.shenyu:shenyu-spring-boot-starter-gateway:jar:2.7.2-SNAPSHOT
(compile)
[ERROR] Could not find artifact
org.apache.shenyu:shenyu-spring-boot-starter-gateway:jar:2.7.2-SNAPSHOT in
apache.snapshots (https://repository.apache.org/snapshots)
```
### Evidence: same change, same module args, only the cache differs
Both runs are on PR #7166, with the identical PR diff (2 files, the token
limiter plugin and its test) and the
identical `MODULE_ARGS="-pl
shenyu-plugin/shenyu-plugin-ai/shenyu-plugin-ai-token-limiter -am -amd"`:
| commit | run | cache step | result |
|---|---|---|---|
| `021431b` |
[35807417260](https://github.com/apache/shenyu/actions/runs/35807417260) |
`Cache hit for: Linux-maven-b66a526b…` / `Cache restored successfully` |
**success** |
| `13eca52` |
[35811455697](https://github.com/apache/shenyu/actions/runs/35811455697) |
`Cache not found for input keys: Linux-maven-b66a526b…, Linux-maven-` |
**failure** |
`13eca52` is a "Merge branch 'master' into fix/token-limiter-window" commit,
so the code being built is the same;
the merge only changed the head SHA and therefore the run. The same commits
build fine on master
([run
35811440161](https://github.com/apache/shenyu/actions/runs/35811440161)),
because the push path
(`build_local_repo`) builds and installs the whole project instead of a
module subset.
The `build` job that fails in a few seconds is only the status gate of the
workflow
(`[[ "failure" == "success" ]] || exit -1`), it mirrors `pr_build` and does
not need its own investigation.
### Why the cache is missing so often
The cache holds `~/.m2/repository` under a repo-wide key (`<os>-maven-${{
hashFiles('**/pom.xml') }}`) with a
`<os>-maven-` prefix fallback, and it is ~988 MB per entry. The repository
currently holds 10 cache entries
totalling about 9.6 GB, and the ones for this key are nearly all scoped to
individual pull request refs:
```
ref=refs/pull/7174/merge 988 MB created 02:37
ref=refs/pull/7107/merge 988 MB created 02:59
ref=refs/pull/7108/merge 988 MB created 02:59
ref=refs/pull/7109/merge 988 MB created 02:58
ref=refs/pull/7110/merge 988 MB created 03:03
ref=refs/pull/7113/merge 988 MB created 02:59
ref=refs/pull/7126/merge 988 MB created 02:59
refs/heads/master setup-java-Linux-x64-maven-… 2551 MB created
09-21
refs/pull/7033/merge setup-java-Linux-x64-maven-… 4092 MB created
02:38
```
That fills the per-repository cache budget, so entries are evicted as other
pull requests run. Two details make
this worse:
- For the `Linux-maven-<hash>` key there is **no entry owned by the default
branch**: the only workflow step that saves that key is `e2e-k8s.yml` ([line
175](https://github.com/apache/shenyu/blob/master/.github/workflows/e2e-k8s.yml#L175)),
which runs on pull requests. Every `ci.yml` cache step (and the ones in
codeql/docker-publish) is `actions/cache/restore@v3` only, and
`build_local_repo` on master never saves either — master shows only
`setup-java-…` entries, which are a different key.
- Because the save happens on the pull request ref, a cache entry is only
restorable by *that* pull request (a run can restore the caches of its own ref
and of the base branch). So the first run of any pull request after its entry
was evicted starts with an empty local repository.
`pr_build`'s restore also sets `fail-on-cache-miss: false`, so a miss is not
reported as such — the build just
runs with an empty `~/.m2` and fails later inside `shenyu-bootstrap`.
The outcome is that many unrelated pull requests are red for this reason.
Recent failing `ci` runs include
`fix-6720-cors-options-chain`, `fix-6721-synchronize-ext-plugins`,
`fix/6826-selector-namespace-id`,
`fix/cache-replacement-order`, `fix/token-limiter-window` and others.
### Suggested fixes
1. **Have the push path on master save the cache** (add
`actions/cache/save@v3` next to the restore that
`build_local_repo` already performs, with the same key and the
`<os>-maven-` prefix for restores). A master
build installs every module into `~/.m2`, which is exactly what a
module-scoped reactor needs, and pull
requests are allowed to restore the base branch's caches.
2. **Do not use a module subset when the cache was not restored**, for
example:
```yaml
if [[ "${{ steps.restore-maven-cache.outputs.cache-hit }}" != "true" ]];
then
MODULE_ARGS="" # a cold local repository cannot resolve the siblings
of shenyu-bootstrap
fi
```
The changed-module scope already falls back to a full build through
`full_build_required`; this makes a cold
cache behave the same way instead of failing.
3. Optionally, reconsider saving a ~1 GB cache per pull request ref, given
the repository budget; saving it only
on the default branch would keep the same benefit without the eviction
churn.
### Labels suggestion
`area/ci`
--
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]
