home-v1-skills-code-agent/corp-v1-channel-delivery
6
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request 'Standardize per-project reusable CI base images' (#4) from docs/base-image-ci-strategy into test

Browse Source
This commit was merged in pull request #4.
This commit is contained in:
jarvis-at-skic
2026-09-06 08:02:10 -07:00
parent 74cbc689ea 2815fdd4b3
commit d63fcb39c0
1 changed files with 14 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
SKILL.md
+14 -1
View File
@@ -1,7 +1,7 @@
--- ---
name: corp-v1-channel-delivery name: corp-v1-channel-delivery
description: "Use when operating or synchronizing a Corp v1 project's delivery channel. Drives coding, unit testing, build and continuous-integration health, attempts safe evidence-based fixes, escalates requirement or architecture contradictions, and maintains Ways of Working and Engineering documentation." description: "Use when operating or synchronizing a Corp v1 project's delivery channel. Drives coding, unit testing, build and continuous-integration health, attempts safe evidence-based fixes, escalates requirement or architecture contradictions, and maintains Ways of Working and Engineering documentation."
version: 1.6.1 version: 1.7.0
author: Hermes Agent author: Hermes Agent
license: MIT license: MIT
metadata: metadata:
@@ -114,6 +114,19 @@ Monitor local builds and Gitea Actions for:
A green local build is not proof that CI or delivery succeeded. Verify the actual remote branch and matching CI task/run. A green local build is not proof that CI or delivery succeeded. Verify the actual remote branch and matching CI task/run.
### Per-project reusable CI base images
Each Corp v1 project should own `corp-v1-<code>/corp-v1-<code>-base-images` when stable runtimes or operating-system tools would otherwise be downloaded repeatedly in application CI.
- Keep one folder per image, with its Dockerfile, machine-readable version/platform metadata, usage documentation, build helper, and smoke contract.
- Pin the upstream base by digest and assert exact runtime/tool versions, architecture, numeric non-root identity, writable workspace, CA trust, Git, shell, and other required tools.
- Build and smoke-test without registry credentials on pull requests. Publish only from the trusted integration branch using a narrowly scoped Harbor robot secret.
- Publish immutable full-source-SHA tags, read back the Harbor artifact digest, and consume the image from project workflows by digest—not `latest`, a mutable version tag, or an unverified local name.
- Extend fail-closed tests to reject broad publication triggers, mutable tags, secret access from candidate/PR paths, shell interpolation, wrong digests, and reintroduced runtime setup actions.
- Prefer the verified job image over repeated runtime or package-manager setup actions. Keep lockfile-frozen application dependency installation in the application repository; do not bake project dependencies into a generic base image.
- Treat the first real Gitea build, runtime smoke test, Harbor publication, digest readback, and a consumer workflow at the exact candidate SHA as separate acceptance layers.
- Repair image or publication failures forward only. Preserve the last known-good digest for consumers until the replacement image and consuming workflow pass exact-head CI.
### Runtime-resource placement ### Runtime-resource placement
CI jobs and developer workstations must not provision databases, queues, object stores, caches, brokers, or other application runtime services. When implementation or validation needs such a resource, provision it under the owning application on the approved shared runtime platform through that project's GitOps repository, then consume it through a governed application or test interface. CI jobs and developer workstations must not provision databases, queues, object stores, caches, brokers, or other application runtime services. When implementation or validation needs such a resource, provision it under the owning application on the approved shared runtime platform through that project's GitOps repository, then consume it through a governed application or test interface.