gsadmin/sencho
1
0
Fork 0
mirror of https://github.com/Studio-Saelix/sencho.git synced 2026-08-05 08:27:42 +00:00
Code Issues Packages Projects Releases Wiki Activity

ci: cut action-minute waste on bot PRs and non-docs pushes (#486)

Browse Source 
Skip the backend, frontend, docker-validate, and e2e jobs on the
chore/refresh-screenshots auto-PR opened by the update-screenshots job.
Screenshot PRs only touch docs/images/ and cannot affect build, lint,
or test surfaces, so running the full PR CI suite on them burns ~6
action minutes per release for zero signal. This mirrors the existing
release-please--branches--main--components--sencho skip.

Also short-circuit sync-docs: when a push to main does not touch any
file under docs/, skip the clone, rsync, and commit steps. rsync
--delete would be a no-op anyway, but spinning up the runner and
cloning sencho-docs still burns ~30s per non-docs merge, which adds
up across multiple merges per day. Requires fetch-depth: 2 so the
detect step can diff HEAD~1 HEAD.

Finally, correct the scan-build comment in docker-publish.yml: the
push-build's amd64 leg reuses layers from the buildkit daemon's
in-memory cache (same job, same daemon), not from the shared registry
buildcache. The cache-from pull is a cold-start fallback for the
first-ever run.
This commit is contained in:
Anso
2026-04-10 14:19:15 -04:00
committed by GitHub
parent e654d92d24
commit 3f9aeb229b
2 changed files with 38 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/workflows/docker-publish.yml
+7 -3
View File
@@ -66,9 +66,13 @@ jobs:
# Build an amd64-only variant into the local daemon first so Trivy can
# scan the exact release artifact before it is tagged and pushed. This
# keeps vulnerable releases out of the `latest` and semver tags that
# users actually pull. The scan-build inherits layers from the shared
# buildcache so the amd64 leg of the subsequent push-build is mostly a
# cache hit; we intentionally do NOT write `cache-to` here because the
# users actually pull. Because the push-build step that follows runs in
# the same job against the same buildkit daemon, it reuses this build's
# layers from the daemon's in-memory cache (observed wall-time: the
# push-build typically finishes faster than the scan-build despite
# producing multi-arch output). The `cache-from` pull is just a
# cold-start fallback for the first-ever run or when the buildkit daemon
# is fresh; we intentionally do NOT write `cache-to` here because the
# push-build below writes a strictly better (multi-arch, mode=max)
# cache entry moments later. The tag lives in the `localhost/` namespace
# so a future `push: false` -> `push: true` mistake cannot publish it.