feat(config,chart): route ClickUp Lists through the config file #48

Merged

ryangr0 merged 1 commit from clickup-routing into development

2026-09-02 08:35:43 +00:00

ryangr0 commented

2026-09-02 08:34:51 +00:00

Owner

feat(config,chart): route ClickUp Lists through the config file

pkg/provider/clickup has been a complete TrackerProvider since it landed —
verified webhooks, reads, write-backs, assignee routing — but the config file
only knew trackers.vikunja, so a ClickUp deployment had to route through the
legacy PLOEG_TARGET_MAP env DSL the file format exists to retire. And the chart
could not deliver PLOEG_CLICKUP_TOKEN or _SECRET at all: they are secrets, and
the plain env: map is the only passthrough it had.

Config: trackers.clickup mirrors trackers.vikunja, with two deliberate
differences.

A clickup entry REQUIRES a pinned id (the List id). The provider has no name
resolver yet, and a name-only entry would boot into a resolution step with
nothing to ask. The error names the entry; when a resolver lands, the
restriction lifts and names become the norm here too.

Scope ids share ONE namespace across trackers, and validation now says so:
the target map keys on the container id alone, so a vikunja project and a
clickup List sharing an id would silently route each other's work. One
seen map across both providers turns that into a boot failure instead.

Chart: tracker.clickup — url, tokenSecret, webhookSecret, doneStatus.
Ingest and write-backs stay independent, exactly as the provider promises:
either secret without the other degrades rather than fails, and an empty block
renders nothing, so no Secret is demanded before it exists.

doneStatus is configuration, not convention, because ClickUp statuses are
per-List custom strings — "for review" on one board, "done" on another —
and guessing would 400 or move tasks to a status nobody chose.

The webhook secret is CAPTURED, never invented: ClickUp generates it on
webhook registration and returns it in the response. The values comment says
so, because the natural instinct after the vikunja block is to generate one.

Golden movement is exactly the new env on the gitlab fixture, which now
carries the full code14 shape: GitLab forge, ClickUp tracker.

Gates: gofmt clean, go vet clean, go build ok, go test ./... ok, helm lint ok,
4 renders ok, helm-golden.sh check ok (helm v4.2.3 as CI pins).

Driving consumer: code14's staging cluster (RFC-0013 phase 4) — its board is ClickUp, and this closes the last gap between the provider that already shipped and a deployment that can actually configure it. Follow-up noted for a ClickUp name resolver so id: pinning can retire here the way it should everywhere.

feat(config,chart): route ClickUp Lists through the config file pkg/provider/clickup has been a complete TrackerProvider since it landed — verified webhooks, reads, write-backs, assignee routing — but the config file only knew `trackers.vikunja`, so a ClickUp deployment had to route through the legacy PLOEG_TARGET_MAP env DSL the file format exists to retire. And the chart could not deliver PLOEG_CLICKUP_TOKEN or _SECRET at all: they are secrets, and the plain `env:` map is the only passthrough it had. Config: `trackers.clickup` mirrors `trackers.vikunja`, with two deliberate differences. A clickup entry REQUIRES a pinned id (the List id). The provider has no name resolver yet, and a name-only entry would boot into a resolution step with nothing to ask. The error names the entry; when a resolver lands, the restriction lifts and names become the norm here too. Scope ids share ONE namespace across trackers, and validation now says so: the target map keys on the container id alone, so a vikunja project and a clickup List sharing an id would silently route each other's work. One `seen` map across both providers turns that into a boot failure instead. Chart: `tracker.clickup` — url, tokenSecret, webhookSecret, doneStatus. Ingest and write-backs stay independent, exactly as the provider promises: either secret without the other degrades rather than fails, and an empty block renders nothing, so no Secret is demanded before it exists. doneStatus is configuration, not convention, because ClickUp statuses are per-List custom strings — "for review" on one board, "done" on another — and guessing would 400 or move tasks to a status nobody chose. The webhook secret is CAPTURED, never invented: ClickUp generates it on webhook registration and returns it in the response. The values comment says so, because the natural instinct after the vikunja block is to generate one. Golden movement is exactly the new env on the gitlab fixture, which now carries the full code14 shape: GitLab forge, ClickUp tracker. Gates: gofmt clean, go vet clean, go build ok, go test ./... ok, helm lint ok, 4 renders ok, helm-golden.sh check ok (helm v4.2.3 as CI pins). Driving consumer: code14's staging cluster (RFC-0013 phase 4) — its board is ClickUp, and this closes the last gap between the provider that already shipped and a deployment that can actually configure it. Follow-up noted for a ClickUp name resolver so `id:` pinning can retire here the way it should everywhere.

ryangr0 added 1 commit

2026-09-02 08:34:51 +00:00

feat(config,chart): route ClickUp Lists through the config file

On Pull Request / checks (pull_request) Successful in 44s

Details

9778959ee3

pkg/provider/clickup has been a complete TrackerProvider since it landed —
verified webhooks, reads, write-backs, assignee routing — but the config file
only knew `trackers.vikunja`, so a ClickUp deployment had to route through the
legacy PLOEG_TARGET_MAP env DSL the file format exists to retire. And the chart
could not deliver PLOEG_CLICKUP_TOKEN or _SECRET at all: they are secrets, and
the plain `env:` map is the only passthrough it had.

Config: `trackers.clickup` mirrors `trackers.vikunja`, with two deliberate
differences.

  A clickup entry REQUIRES a pinned id (the List id). The provider has no name
  resolver yet, and a name-only entry would boot into a resolution step with
  nothing to ask. The error names the entry; when a resolver lands, the
  restriction lifts and names become the norm here too.

  Scope ids share ONE namespace across trackers, and validation now says so:
  the target map keys on the container id alone, so a vikunja project and a
  clickup List sharing an id would silently route each other's work. One
  `seen` map across both providers turns that into a boot failure instead.

Chart: `tracker.clickup` — url, tokenSecret, webhookSecret, doneStatus.
Ingest and write-backs stay independent, exactly as the provider promises:
either secret without the other degrades rather than fails, and an empty block
renders nothing, so no Secret is demanded before it exists.

doneStatus is configuration, not convention, because ClickUp statuses are
per-List custom strings — "for review" on one board, "done" on another —
and guessing would 400 or move tasks to a status nobody chose.

The webhook secret is CAPTURED, never invented: ClickUp generates it on
webhook registration and returns it in the response. The values comment says
so, because the natural instinct after the vikunja block is to generate one.

Golden movement is exactly the new env on the gitlab fixture, which now
carries the full code14 shape: GitLab forge, ClickUp tracker.

Gates: gofmt clean, go vet clean, go build ok, go test ./... ok, helm lint ok,
4 renders ok, helm-golden.sh check ok (helm v4.2.3 as CI pins).

ryangr0 merged commit dacd28f239 into development

2026-09-02 08:35:43 +00:00

ryangr0 referenced this pull request from a commit

2026-09-02 08:35:44 +00:00

Merge pull request 'feat(config,chart): route ClickUp Lists through the config file' (#48) from clickup-routing into development

Commenting is not possible because the repository is archived.

No reviewers

No labels

No milestone

No project

No assignees

1 participant

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

webgrip/ploeg!48

No description provided.

Rows
Columns