#599 extension push: optionally sync the published bundle to the manifest `repository:` (git mirror)

Opened by stateless · 6/9/2026

Problem

Publishing an extension is effectively two steps today:

swamp extension push uploads the bundle to the registry.
A manual, separate git push of the same source to the extension's public repo — the one already declared in the manifest repository:.

The two drift easily. It is trivial to push to the registry and forget the git mirror, leaving the public source lagging the published version. We hit exactly this: the registry was at 2026.06.09.1 while the public mirror sat at 2026.06.06.3 until it was caught by hand.

Proposed solution

Have swamp extension push optionally also publish the bundle to the manifest's repository: git remote. swamp already computes the exact publish-safe fileset (manifest models: + additionalFiles:) for the registry archive, and the manifest already declares repository: — so both the content and the destination are already known to the CLI.

A --mirror / --git flag (or a manifest field such as mirror: true) would:

check out repository: (clone if absent),
write the same bundle files into it,
commit Sync to <version>,
push.

This makes registry/git drift impossible by construction — the public source and the published version can't diverge if one command does both.

Keep it opt-in (some authors publish registry-only). Reuse the environment's git credentials (SSH deploy key / gh).

Alternatives considered

Manual two-step (status quo): drifts, as above.
A separate swamp extension mirror subcommand: better than manual, but still a second command to remember; folding it into push is the drift-proof option.
A local skill/wrapper around the git push: works (we built one as a stopgap), but reimplements what swamp already has — the publish-safe fileset.

02Bog Flow

Closed

6/12/2026, 10:18:02 AM

No activity in this phase yet.

03Sludge Pulse

stack72 commented 6/12/2026, 10:14:54 AM

@stateless thanks for filing this — the drift problem is real and we've felt it ourselves.

We looked at the --mirror / --git approach but we're not ready to bring git-based semantics into extension push right now. The surface area is significant: git vs jj, SSH vs HTTPS credentials, deploy keys, clone-if-absent logic, conflict handling — and we'd need to support all of that reliably across platforms. It's more than a flag.

For now, this is solvable with a swamp workflow using command/shell:

name: extension-publish
description: Publish extension to registry and sync to git mirror
version: 1
jobs:
  - name: publish
    steps:
      - name: registry-push
        description: Push extension bundle to the registry
        task:
          type: model_method
          modelType: "command/shell"
          modelName: extension-registry-push
          methodName: execute
          inputs:
            run: swamp extension push
      - name: git-push
        description: Push source to the git mirror
        dependsOn:
          - step: registry-push
            condition:
              type: succeeded
        task:
          type: model_method
          modelType: "command/shell"
          modelName: extension-git-push
          methodName: execute
          inputs:
            run: git push

The dependsOn ensures the git push only fires if the registry push succeeds, so the mirror can't get ahead of the registry. You get run history and can schedule it if needed.

This doesn't make drift impossible by construction the way a native flag would, but it reduces it to "run the workflow instead of the bare command" — which is a much smaller gap than the manual two-step.

We do want to look at a more integrated flow in the future, but we want to get the design right rather than ship something half-baked that locks us into specific VCS assumptions. Keeping this issue open to track that.

stateless commented 6/15/2026, 5:14:56 AM

Swamp is a wide brush and as more of sysop vs a developer I rely on swamp + the model to tell me what to do vs digging into the code vs what I think should be happen. I've not entirely figured out workflows. I wonder if this example and more documentation about how to use swamp might be useful?