Skip to main content

Prepare the Sandbox release

Use this checklist to move the merged E-Shop v1 application from TO_BE_RELEASED to a verifiable internal Sandbox deployment. The current application head is commit 3be141af869220620672b04681d335fb2803f425, which adds the E-Shop v1 Argo CD application manifests after the artifact-publication workflow was merged.

Current release gate​

A metadata-only organization Actions check on 2026-08-27 now finds the required secret name:

HL_V1_HARBOR_ROBOT_GITEA_ACTIONS_V1_SECRET

No secret value was requested, read, printed, or stored. Default-head Actions run 3203 attempted authenticated publication for exact source SHA 3be141af869220620672b04681d335fb2803f425, but task 1448 failed during Authenticate artifact clients to Harbor with an unauthorized response. Image and chart build/push steps were skipped, so no immutable Harbor artifact exists for deployment. The separate validation task 1449 remains independent of this publication gate.

Required infrastructure action​

  1. Verify or rotate the configured Harbor robot credential through the approved secret-management path and confirm that the robot can authenticate to harbor-v1.apps.lego-cloud.eu and push to the public library project.
  2. Keep the credential value inside Gitea/Harbor secret controls; do not paste it into Discord, documentation, a repository, logs, or an agent prompt.
  3. Re-run the default-head artifact workflow and require exact-SHA success before treating either artifact as published.

Publication and deployment sequence​

  1. Resolve the Harbor authentication rejection without exposing credential values.
  2. Trigger the governed default-head artifact workflow and require successful publication of both the storefront image and OCI Helm chart from the exact application head.
  3. Record immutable image and chart references; do not deploy latest as release evidence.
  4. Update the approved Gondor v1 template source, render it through its repository-native command, and verify only E-Shop resources changed.
  5. Deploy to the internal home-lab target through GitOps and verify the gallery, cart, health endpoint, and fail-closed checkout state before injecting payment configuration.
  6. Inject PayPal Sandbox-only credentials through the approved runtime secret reference, then verify create, capture, and confirmation behavior without recording credential or sensitive payment payloads.

Rollback boundary​

Retain the previous known-good image digest and rendered GitOps revision before deployment. A failed health, gallery, cart, Sandbox, or confirmation check blocks completion and triggers a reviewed GitOps rollback to those immutable references. Rollback does not authorize production PayPal, vendor-account changes, purchases, or destructive infrastructure operations.

Completion evidence​

Release completion requires all of the following:

  • exact application source SHA;
  • exact-head successful publication task ID;
  • immutable image digest and chart version/digest;
  • template-source and rendered GitOps commit SHAs;
  • deployment health and route readback;
  • Sandbox acceptance evidence with secrets excluded;
  • updated canonical Task transitions and deterministic Feature/Epic roll-up.

A merge, green validation workflow, mutable tag, or healthy pod alone does not move governed scope to DONE.

Last updated on