Swarmby Myrik

Jira integration

  1. 1
    In Settings, fill in Jira domain, email, API token, and generate a webhook secret.
  2. 2
    In Jira (Settings → System → Webhooks), create a webhook:
    • URL: https://swarm.myrik.in/api/webhooks/jira with an X-Webhook-Secret header
    • Events: Issue created, Issue updated, Comment created
    • JQL (optional): labels = swarm
  3. 3
    Add the label "swarm" to any issue — the description becomes the spec, a run starts automatically, and progress posts back as comments.
  4. 4
    Configure additional label presets in Settings → Label Configs with custom pipeline options and repo selections per label.
Keep in mind — to test Jira, create a real labeled ticket — don't hand-craft a webhook payload. Simulated payloads skip Jira-side validation and mask label/comment/payload bugs.

Pull-request outcomes (learning signal)

Swarm tracks what happens to each PR it opens — merged, merged after human edits, or closed without merging — and feeds that "accept signal" back into its evaluation corpus. Two ways it resolves:

  1. 1
    Webhook (real-time): point a GitHub webhook at https://swarm.myrik.in/api/webhooks/github with an X-Hub-Signature-256 secret (the same GitHub webhook secret you set in Settings), and subscribe the Pull requests event. A PR closing resolves its outcome immediately.
  2. 2
    Poll (automatic backstop): if you don't configure the webhook, Swarm still resolves outcomes on a slow background poll of recently-finished runs — no setup required, just higher latency.
Keep in mind — the same webhook endpoint also powers GitHub issue triggers (label an issue to start a run). Subscribing both Issues and Pull requests events covers triggering and the accept signal.

Deployments & build history

/deployments shows the currently-deployed commit (SHA + build time) and the last 50 commits leading up to it, captured at deploy time. The live commit is also shown in the sidebar footer.

Each commit links to GitHub; conventional-commit prefixes get a colored badge, and the live build gets a live badge.

Keep in mind — the bare /api/version URL is edge-cached and can serve a stale build string right after a deploy — compare the running task definition's image digest if you need certainty.

Rollback & retention

Production keeps the last 5 ECS task definitions and last 5 ECR images, so you can revert to a recent deploy by pointing the ECS service at a prior revision (full command in docs/deployment.md).

Data is not rolled back — DynamoDB tables are shared across revisions. A code rollback won't undo a schema change that corrupted data.
Keep in mind — a deploy replaces the single task and briefly interrupts in-flight runs; they auto-resume on the new container, but it's worth checking for active runs before shipping.