spike: subtree git archive <tag>:<subdir> + sha256 sidecar attachment-from-hook #812

Open
opened 2026-07-18 19:54:37 +00:00 by jmiller · 1 comment
Owner

De-risk the packaging hook: confirm the forge can (in-process) run a subtree archive of entry_point at a tag and create/attach release assets from a hook. The subtree-archive helper and hook attachment path were NOT located in source during assessment (tree API truncates at 1000 entries).


Part of the MokoGIT release-system redesign (all-platforms assessment, 2026-07-18). Hybrid direction: server-side packaging, build/publish stay on runners.
Authored-by: Moko Consulting

De-risk the packaging hook: confirm the forge can (in-process) run a subtree archive of `entry_point` at a tag and create/attach release assets from a hook. The subtree-archive helper and hook attachment path were NOT located in source during assessment (tree API truncates at 1000 entries). --- Part of the MokoGIT release-system redesign (all-platforms assessment, 2026-07-18). Hybrid direction: server-side packaging, build/publish stay on runners. Authored-by: Moko Consulting
jmiller added the ci-cd label 2026-07-18 19:54:37 +00:00
Author
Owner

Spike verdict: GO

The forge can package on-release entirely in-process — no build scripts, no publish tokens. Every capability already exists in-tree; services/release/checksum.go:GenerateReleaseChecksums is a working template of the exact pattern.

  • Hook: inline in services/release/release.go:CreateRelease (before the existing checksum call, ~:259) and the UpdateRelease path (draft→publish); or a custom Notifier.
  • Archive: modules/gitrepo/archive.go:CreateArchive shells git archive --format=zip <commit> <paths...> — subtree via Paths=[entry_point], full-repo via Paths=nil; commit = rel.Sha1.
  • sha256 + attach: reuse checksum.go's crypto/sha256 + attachment_service.NewAttachment (stream the zip via io.Pipe).
  • entry_point: RepoMetadata.EntryPoint via GetRepoMetadata(ctx, rel.RepoID) (already used in updateserver/joomla.go).
  • Bonus: the Joomla feed already prefers a .zip+.sha256 asset and falls back to /archive — this makes it primary.

Implementation estimate: new services/release/packaging.go + 2 call-site edits in release.go.

Caveats to handle in #809: runs inline/synchronous (stream via io.Pipe to avoid buffering large zips; async/queue possible but unverified as preferred); hook UpdateRelease too; idempotent replace-on-rerun is net-new; NewAttachment bypasses the release size cap.

Unblocks #809.

Authored-by: Moko Consulting

## Spike verdict: **GO** The forge can package on-release entirely in-process — no build scripts, no publish tokens. Every capability already exists in-tree; `services/release/checksum.go:GenerateReleaseChecksums` is a working template of the exact pattern. - **Hook:** inline in `services/release/release.go:CreateRelease` (before the existing checksum call, ~:259) and the `UpdateRelease` path (draft→publish); or a custom `Notifier`. - **Archive:** `modules/gitrepo/archive.go:CreateArchive` shells `git archive --format=zip <commit> <paths...>` — subtree via `Paths=[entry_point]`, full-repo via `Paths=nil`; commit = `rel.Sha1`. - **sha256 + attach:** reuse `checksum.go`'s `crypto/sha256` + `attachment_service.NewAttachment` (stream the zip via `io.Pipe`). - **entry_point:** `RepoMetadata.EntryPoint` via `GetRepoMetadata(ctx, rel.RepoID)` (already used in `updateserver/joomla.go`). - **Bonus:** the Joomla feed already prefers a `.zip`+`.sha256` asset and falls back to `/archive` — this makes it primary. **Implementation estimate:** new `services/release/packaging.go` + 2 call-site edits in `release.go`. **Caveats to handle in #809:** runs inline/synchronous (stream via io.Pipe to avoid buffering large zips; async/queue possible but unverified as preferred); hook UpdateRelease too; idempotent replace-on-rerun is net-new; `NewAttachment` bypasses the release size cap. Unblocks #809. Authored-by: Moko Consulting
Sign in to join this conversation.