feat(quickstack): inherit app runtime configuration safely
Nuvisphere/Platform-CI: Immutable QuickStack OCI deployment / Build once and deploy exact digest (push) Successful in 31s
Platform CI tests / QuickStack deploy action tests (pull_request) Successful in 36s
Nuvisphere/Platform-CI: Immutable QuickStack OCI deployment / Build once and deploy exact digest (pull_request) Successful in 23s
Nuvisphere/Platform-CI: Immutable QuickStack OCI deployment / Build once and deploy exact digest (push) Successful in 31s
Platform CI tests / QuickStack deploy action tests (pull_request) Successful in 36s
Nuvisphere/Platform-CI: Immutable QuickStack OCI deployment / Build once and deploy exact digest (pull_request) Successful in 23s
This commit is contained in:
@@ -68,6 +68,7 @@ Use manifest version 2 when one image serves multiple applications or Production
|
||||
"artifact": "web",
|
||||
"appId": "app-worker-staging",
|
||||
"dependsOn": ["web"],
|
||||
"environmentFromAppId": "app-staging",
|
||||
"environment": { "PROCESS": "worker" }
|
||||
}
|
||||
]
|
||||
@@ -96,6 +97,15 @@ an Actions secret exposed to the workflow environment. Values are passed to
|
||||
the command line as build arguments. The Dockerfile consumes them with
|
||||
`RUN --mount=type=secret,id=<id>,required=true ...`.
|
||||
|
||||
`environmentFromAppId` is optional and copies the existing QuickStack runtime
|
||||
environment from another application before applying the target application's
|
||||
declared `environment` and `secretEnvironment` overrides. This is intended for
|
||||
workers that share backend credentials with an API without duplicating secret
|
||||
values in Git or Actions. `volumeMountPaths` can map an existing QuickStack
|
||||
volume ID or shared-volume ID to a safe absolute container path; it never
|
||||
creates or replaces a volume. QuickStack's deployment identity variable is
|
||||
never inherited from the source application.
|
||||
|
||||
Candidate pipelines build every artifact once, push `sha-<commit>`, resolve the registry digest and deploy applications in dependency order. A pull request into a promotion branch must originate from `source.branch`; it pulls and verifies the already tested `sha-<commit>` candidates without rebuilding or deploying them. Promotion pushes require a merge parent with an identical Git tree, pull the existing candidate, verify required container files, add the SemVer alias, deploy the exact digests, create the immutable tag and publish the canonical Gitea release. Tag creation does not trigger another scoped pipeline because the workflow listens only to branch pushes.
|
||||
|
||||
Scoped workflows can distribute version 2 artifact builds across independent
|
||||
|
||||
Reference in New Issue
Block a user