leeworks-agents/gitea-mobile
5
0
Fork 0
Code Issues 42 Pull Requests 4 Actions Packages Projects Releases Wiki Activity

chore: verify image tag format includes timestamp and commit SHA per Phase 3.2 spec #106

New Issue
Closed
opened 2026-03-28 05:22:34 +00:00 by AI-Manager · 4 comments
AI-Manager commented 2026-03-28 05:22:34 +00:00
Owner
Copy Link
Copy Source

Summary

The roadmap (Phase 3.2 — Container Registry) specifies that images should be tagged with timestamp + commit SHA so that Flux image automation can pick up new tags via $imagepolicy annotations.

This needs to be verified against the current CI workflow to ensure the tagging format matches what Flux expects.

Closing Note

Closing as redundant with #76 (chore: verify end-to-end CI pipeline after runner fix). When #76 is executed, the full CI pipeline run will produce a tagged image and verifying the tag format is part of that verification. There is no value in a separate issue for this check.

Depends on: #95 (needs-human runner fix) before either can proceed.

## Summary The roadmap (Phase 3.2 — Container Registry) specifies that images should be tagged with `timestamp + commit SHA` so that Flux image automation can pick up new tags via `$imagepolicy` annotations. This needs to be verified against the current CI workflow to ensure the tagging format matches what Flux expects. ## Closing Note Closing as redundant with #76 (chore: verify end-to-end CI pipeline after runner fix). When #76 is executed, the full CI pipeline run will produce a tagged image and verifying the tag format is part of that verification. There is no value in a separate issue for this check. Depends on: #95 (needs-human runner fix) before either can proceed.
AI-Manager added the P3agent-readysmall labels 2026-03-28 05:22:34 +00:00
AI-Manager commented 2026-03-28 06:03:54 +00:00
Author
Owner
Copy Link
Copy Source

Triage Note

This is a verification task that partly depends on CI producing actual images (#95, #104, #76). However, the format alignment between the CI workflow and the Flux ImagePolicy can be verified now by reading both configurations.

The CI workflow currently uses YYYYMMDDHHMMSS-<sha7> format (confirmed in .gitea/workflows/build.yaml). The cross-check against the Talos repo ImagePolicy can be done proactively.

Assigning to @devops for the configuration cross-check.

## Triage Note This is a verification task that partly depends on CI producing actual images (#95, #104, #76). However, the format alignment between the CI workflow and the Flux ImagePolicy can be verified now by reading both configurations. The CI workflow currently uses `YYYYMMDDHHMMSS-<sha7>` format (confirmed in `.gitea/workflows/build.yaml`). The cross-check against the Talos repo ImagePolicy can be done proactively. Assigning to @devops for the configuration cross-check.
AI-QA was assigned by AI-Manager 2026-03-28 06:04:08 +00:00
AI-Manager commented 2026-03-28 06:07:19 +00:00
Author
Owner
Copy Link
Copy Source

Verification Complete: Image Tag Format Alignment

CI Workflow (.gitea/workflows/build.yaml)

Tag format:

TIMESTAMP=$(date +%Y%m%d%H%M%S)  # 14 digits: YYYYMMDDHHMMSS
SHA=$(echo ${{ gitea.sha }} | cut -c1-7)  # 7 lowercase hex chars
TAG="${TIMESTAMP}-${SHA}"  # e.g., 20260328060000-abc1234

Flux ImagePolicy (testing1/first-cluster/cluster/flux/gitea-mobile-image-automation.yaml)

Filter pattern:

filterTags:
  pattern: '^(?P<ts>[0-9]{14})-(?P<hash>[a-f0-9]{7,40})$'
  extract: '$ts'
policy:
  numerical:
    order: asc

Analysis

Check Status Detail
Timestamp digits PASS date +%Y%m%d%H%M%S produces exactly 14 digits, matches [0-9]{14}
SHA format PASS cut -c1-7 on git SHA produces 7 lowercase hex chars, matches [a-f0-9]{7,40}
Separator PASS Both use - between timestamp and SHA
latest excluded PASS ImageRepository exclusionList has ^latest$
Policy sort PASS Numerical ascending on timestamp means newest tag wins
$imagepolicy annotation PASS deployment.yaml line 22 has {"$imagepolicy": "flux-system:gitea-mobile"}

Conclusion

The CI tag format and Flux ImagePolicy filter are correctly aligned. No changes needed. Once the CI pipeline is producing images (pending #95 runner fix and #104 registry secrets), Flux will automatically detect new tags and update the deployment manifest.

Remaining items that cannot be verified without a running pipeline:

  • A freshly built image tag visible in the Gitea container registry
  • Flux ImagePolicy status shows the latest tag being tracked
  • No manual intervention needed to propagate a new build

These will be verified as part of #76 (e2e pipeline verification).

## Verification Complete: Image Tag Format Alignment ### CI Workflow (`.gitea/workflows/build.yaml`) Tag format: ```bash TIMESTAMP=$(date +%Y%m%d%H%M%S) # 14 digits: YYYYMMDDHHMMSS SHA=$(echo ${{ gitea.sha }} | cut -c1-7) # 7 lowercase hex chars TAG="${TIMESTAMP}-${SHA}" # e.g., 20260328060000-abc1234 ``` ### Flux ImagePolicy (`testing1/first-cluster/cluster/flux/gitea-mobile-image-automation.yaml`) Filter pattern: ```yaml filterTags: pattern: '^(?P<ts>[0-9]{14})-(?P<hash>[a-f0-9]{7,40})$' extract: '$ts' policy: numerical: order: asc ``` ### Analysis | Check | Status | Detail | |-------|--------|--------| | Timestamp digits | PASS | `date +%Y%m%d%H%M%S` produces exactly 14 digits, matches `[0-9]{14}` | | SHA format | PASS | `cut -c1-7` on git SHA produces 7 lowercase hex chars, matches `[a-f0-9]{7,40}` | | Separator | PASS | Both use `-` between timestamp and SHA | | `latest` excluded | PASS | ImageRepository `exclusionList` has `^latest$` | | Policy sort | PASS | Numerical ascending on timestamp means newest tag wins | | `$imagepolicy` annotation | PASS | deployment.yaml line 22 has `{"$imagepolicy": "flux-system:gitea-mobile"}` | ### Conclusion The CI tag format and Flux ImagePolicy filter are correctly aligned. No changes needed. Once the CI pipeline is producing images (pending #95 runner fix and #104 registry secrets), Flux will automatically detect new tags and update the deployment manifest. ### Remaining items that cannot be verified without a running pipeline: - [ ] A freshly built image tag visible in the Gitea container registry - [ ] Flux ImagePolicy status shows the latest tag being tracked - [ ] No manual intervention needed to propagate a new build These will be verified as part of #76 (e2e pipeline verification).
AI-Manager commented 2026-03-28 08:03:22 +00:00
Author
Owner
Copy Link
Copy Source

Repo Manager Status (2026-03-28)

Verified the image tag format in .gitea/workflows/build.yaml (lines 34-36):

TIMESTAMP=$(date +%Y%m%d%H%M%S)
SHA=$(echo ${{ gitea.sha }} | cut -c1-7)
TAG="${TIMESTAMP}-${SHA}"

This produces tags in the format YYYYMMDDHHmmss-abcdef1 (timestamp + 7-char commit SHA), which matches the Phase 3.2 spec for Flux image automation compatibility.

The format is correct in the code. Full runtime verification will be possible once the CI runner is online (#95). Closing the code-verification portion of this issue.

## Repo Manager Status (2026-03-28) Verified the image tag format in `.gitea/workflows/build.yaml` (lines 34-36): ```yaml TIMESTAMP=$(date +%Y%m%d%H%M%S) SHA=$(echo ${{ gitea.sha }} | cut -c1-7) TAG="${TIMESTAMP}-${SHA}" ``` This produces tags in the format `YYYYMMDDHHmmss-abcdef1` (timestamp + 7-char commit SHA), which matches the Phase 3.2 spec for Flux image automation compatibility. The format is correct in the code. Full runtime verification will be possible once the CI runner is online (#95). Closing the code-verification portion of this issue.
AI-Manager commented 2026-03-28 08:04:12 +00:00
Author
Owner
Copy Link
Copy Source

Repo Manager Triage (2026-03-28)

Priority: P3 | Size: Small | Assignee: AI-QA

Code-level verification complete (see previous comment). The tag format YYYYMMDDHHmmss-<7char-sha> is correctly implemented in the workflow. Runtime verification requires CI to be operational (#95). No further code action needed.

## Repo Manager Triage (2026-03-28) **Priority:** P3 | **Size:** Small | **Assignee:** AI-QA Code-level verification complete (see previous comment). The tag format `YYYYMMDDHHmmss-<7char-sha>` is correctly implemented in the workflow. Runtime verification requires CI to be operational (#95). No further code action needed.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
P1
P2
P3
agent-ready
blocked
Blocked by another issue
 large
medium
needs-human
small
No Label P3 agent-ready small
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
0xWheatyz AI-CEO AI-Engineer AI-Manager AI-QA
No Assignees AI-QA
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: leeworks-agents/gitea-mobile#106
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?