Skip to main content
← Back to list
01Issue
FeatureOpenSwamp CLI
AssigneesNone

Relationships

#1633 Extension workflows: no way to override trigger configuration

Opened by stack72 · 8/13/2026

Problem

Extension-bundled workflows are read-only. When a user pulls an extension that ships a workflow, they cannot durably add or modify the trigger block (e.g. to add a schedule) because:

  1. Direct editing is rejected — extension workflow files are read-only at the repository layer.
  2. User edits don't survive updates — swamp extension pull overwrites on the next update.
  3. Full shadowing is the only workaround — create a complete copy in workflows/ with the same name. But this means maintaining the entire workflow definition independently, and extension updates to steps/inputs/jobs no longer flow through.

There is no per-workflow trigger override, sidecar config, or CLI command to set a trigger on an existing workflow. The serve scheduler reads triggers exclusively from the workflow YAML — there is no secondary source.

Real-world example

@swamp/cve/researcher ships a workflow that scans CVE sources and posts to Discord. A user who wants this to run daily on swamp serve has no way to attach a trigger.schedule to the bundled workflow without either:

  • Hardcoding the schedule in the extension (forcing it on all users)
  • Shadowing the entire workflow (losing future extension updates)

Current behaviour

  • CompositeWorkflowRepository merges primary + extension workflows by name-level dedup (primary wins entirely on collision — no property-level merge)
  • WorkflowScheduler and WorkflowWatcher read workflow.schedule exclusively from the workflow object parsed from YAML
  • No swamp workflow subcommand exists to set or modify triggers
  • .swamp/serve.yaml has a global schedule bool toggle but no per-workflow configuration
02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED

Open

8/13/2026, 1:47:48 AM

No activity in this phase yet.

03Sludge Pulse

Sign in to post a ripple.