Spike: Auto-bump remote-base ?ref= SHA in pal-e-deployments via Woodpecker #11

New issue

Open

opened 2026-05-01 12:25:55 +00:00 by forgejo_admin · 0 comments

forgejo_admin commented

2026-05-01 12:25:55 +00:00

Contributor

Type

Spike

Lineage

Discovered by QA agent on PR forgejo_admin/pal-e-deployments#138 — first overlay in pal-e-deployments to use the remote-base pattern (resources: pointing at notion-mcp-remote/k8s/ via pinned SHA). The QA review surfaced the operational gap that follow-on commits to k8s/ require a manual write-back PR to pal-e-deployments to bump ?ref=.

Repo

forgejo_admin/notion-mcp-remote (where the Woodpecker step would live), with cross-repo write to forgejo_admin/pal-e-deployments.

Question

Should we add a Woodpecker step to notion-mcp-remote that, on push to main affecting k8s/, opens a Forgejo PR in pal-e-deployments bumping the ?ref= SHA in overlays/notion-mcp-remote/prod/kustomization.yaml — mirroring how ArgoCD Image Updater auto-bumps image tags?

What to Explore

How often does notion-mcp-remote/k8s/ actually change post-stabilization? (Empirical evidence — git log, projected change rate.)
Existing patterns: does any pal-e service already do cross-repo Forgejo PR automation? (Check Image Updater's mechanism — it writes to git directly, doesn't open PRs. Check Woodpecker examples in pal-e-platform.)
Auth model: a Woodpecker step in repo A opening a PR in repo B needs a Forgejo token with write access to repo B. Where would that secret live? Robot account?
Generalization: does convention-kustomize-overlay need to recommend this pattern for any service using remote-base, or is notion-mcp-remote going to remain the only such service?
Cost/benefit: weigh implementation effort against the friction of the manual 2-PR cascade.

Success Criteria

Question is answered with evidence (change rate data + auth model + generalization analysis), not opinion
If "build": follow-up Feature ticket created with design sketch (Woodpecker step + cross-repo auth + PR template)
If "defer": deferral trigger documented (e.g., "open a feature ticket if k8s/ change rate exceeds 1/month")
If "reject": rationale documented in closing comment

Time-box

Maximum: 1 session (~2 hours of investigation). If time-box expires without an answer, close the spike, document findings, and escalate to Lucas.

project-notion-mcp-remote — project this affects
forgejo_admin/pal-e-deployments #138 — PR that surfaced this
convention-kustomize-overlay — convention that may need a Remote Base Variant section (separate /update-docs scope)
arch-deployment-notion-mcp-remote

### Type Spike ### Lineage Discovered by QA agent on PR `forgejo_admin/pal-e-deployments#138` — first overlay in pal-e-deployments to use the remote-base pattern (`resources:` pointing at `notion-mcp-remote/k8s/` via pinned SHA). The QA review surfaced the operational gap that follow-on commits to `k8s/` require a manual write-back PR to `pal-e-deployments` to bump `?ref=`. ### Repo `forgejo_admin/notion-mcp-remote` (where the Woodpecker step would live), with cross-repo write to `forgejo_admin/pal-e-deployments`. ### Question Should we add a Woodpecker step to `notion-mcp-remote` that, on push to main affecting `k8s/`, opens a Forgejo PR in `pal-e-deployments` bumping the `?ref=` SHA in `overlays/notion-mcp-remote/prod/kustomization.yaml` — mirroring how ArgoCD Image Updater auto-bumps image tags? ### What to Explore - How often does `notion-mcp-remote/k8s/` actually change post-stabilization? (Empirical evidence — git log, projected change rate.) - Existing patterns: does any pal-e service already do cross-repo Forgejo PR automation? (Check Image Updater's mechanism — it writes to git directly, doesn't open PRs. Check Woodpecker examples in `pal-e-platform`.) - Auth model: a Woodpecker step in repo A opening a PR in repo B needs a Forgejo token with write access to repo B. Where would that secret live? Robot account? - Generalization: does `convention-kustomize-overlay` need to recommend this pattern for any service using remote-base, or is `notion-mcp-remote` going to remain the only such service? - Cost/benefit: weigh implementation effort against the friction of the manual 2-PR cascade. ### Success Criteria - [ ] Question is answered with evidence (change rate data + auth model + generalization analysis), not opinion - [ ] If "build": follow-up Feature ticket created with design sketch (Woodpecker step + cross-repo auth + PR template) - [ ] If "defer": deferral trigger documented (e.g., "open a feature ticket if `k8s/` change rate exceeds 1/month") - [ ] If "reject": rationale documented in closing comment ### Time-box Maximum: 1 session (~2 hours of investigation). If time-box expires without an answer, close the spike, document findings, and escalate to Lucas. ### Related - `project-notion-mcp-remote` — project this affects - `forgejo_admin/pal-e-deployments #138` — PR that surfaced this - `convention-kustomize-overlay` — convention that may need a Remote Base Variant section (separate `/update-docs` scope) - `arch-deployment-notion-mcp-remote`