will/eec-campaigns
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Confirm API shapes against the exact deployed listmonk version (v6.2.0)
Sync campaigns / sync (push) Successful in 7s
Details

Browse Source 
Previously verified against master; re-checked cmd/campaigns.go,
cmd/subscribers.go, and cmd/handlers.go at the v6.2.0 tag specifically
(the version pinned in reground-infrastructure's group_vars) since that's
what's actually running. Everything matched exactly — no code changes,
just removes the "confirm against your actual version" hedge from the
README now that it's been done.
This commit is contained in:
Will Estes
2026-07-10 09:00:51 -04:00
parent a630a8f8ab
commit 35142970fb
1 changed files with 2 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+2 -3
View File
@@ -100,12 +100,11 @@ Run once via the `Sync default campaign template` workflow (`workflow_dispatch`,
## Open items
Every request shape in `internal/listmonk` is now confirmed against `knadh/listmonk`'s actual Go source (not just its docs, which are incomplete on a few of these): the campaign create/update payload, its `media` field for attachments (listmonk's request/response asymmetry — requests send plain IDs under `media`, responses echo full objects back under the same key), create always defaulting to `draft` regardless of any caller-supplied status, the test-send endpoint's `subscribers` field, the query-based bulk list action (`PUT /api/subscribers/query/lists`) segmentation uses, and the template API (`GET`/`POST /api/templates`, `PUT /api/templates/:id`, fields `name`/`type`/`body`/`is_default`). What's left is genuinely operational, not code:
Every request shape in `internal/listmonk` — the campaign create/update payload, its `media` field for attachments (listmonk's request/response asymmetry: requests send plain IDs under `media`, responses echo full objects back under the same key), create always defaulting to `draft` regardless of any caller-supplied status, the test-send endpoint's `subscribers` field, the query-based bulk list action (`PUT /api/subscribers/query/lists`), and the template API (`GET`/`POST /api/templates`, `PUT /api/templates/:id`, fields `name`/`type`/`body`/`is_default`) — is confirmed directly against `knadh/listmonk`'s actual Go source at **`v6.2.0`**, the exact version this org runs (`listmonk_version` in `reground-infrastructure`'s `group_vars/all/vars.yml`), not just its docs (which are incomplete on a few of these) or an assumed-current `master`. What's left is genuinely operational, not code:
- **Running the `Sync default campaign template` workflow at least once** — the template file is committed, but nothing pushes it into listmonk until that workflow (or `campaigns template ...` locally) actually runs.
- **Provisioning the dedicated listmonk API user and pasting its token into this repo's Gitea secrets** (see Deploying below) hasn't happened yet.
- **Provisioning the dedicated listmonk API user and pasting its token into this repo's Gitea secrets** — `reground-infrastructure` now has a `campaigns` role/playbook for the first half (see that repo); pasting the resulting token into Gitea is still a manual step (nothing automates writing Gitea repo secrets today).
- **Gitea Actions' tag-push and `workflow_dispatch` triggers** are standard, long-supported Actions syntax and the runner already successfully uses `uses: actions/checkout@v4` elsewhere in this org, so this should work as written — but it's still worth confirming the first time `send.yml` actually fires.
- The source was read against `knadh/listmonk`'s `master` branch; if the live instance runs a substantially older or newer version, a quick diff against its own `cmd/campaigns.go`/`cmd/subscribers.go`/`cmd/templates.go` is cheap insurance before the first real send.
## Deploying