Skip to content

DX: explicit triggers check CI step with actionable error (drift is already caught — don't add redundant enforcement) #116

@khaliqgant

Description

@khaliqgant

TL;DR for whoever picks this up

Catalog drift is ALREADY enforced in CI — do not add new enforcement. This is a pure developer-experience polish: make the existing drift failure tell you what to do instead of dumping an opaque object diff.

Background

The known-trigger catalog (packages/core/src/triggers/catalog.generated.{ts,json} + adapters-without-known-triggers.generated.json) is a committed, hand-regenerated artifact. You update it by running:

adapter-core triggers generate

There is no GitHub Action that auto-generates or commits it (verified: ci.yml is just npm citurbo buildturbo typechecknpm test; the only git commit/push in workflows is the release bump in publish.yml).

Drift is nonetheless caught today, because packages/core/tests/triggers/catalog-generator.test.ts re-derives the catalog from the live adapters and asserts the committed files match:

test("generated trigger catalog is in sync with adapter supportedEvents", )
  const generation = await generateTriggerCatalog(repoRoot);
  assert.deepEqual(catalogJson, generation.catalog);
  assert.equal(catalogTs, renderTriggerCatalogModule(generation));

That test runs in CI via npm test (Build & Test). So if someone changes an adapter's supportedEvents()/mapping.yaml and forgets to regenerate, the build is already red and the PR can't merge. The CLI also has adapter-core triggers check (packages/core/src/cli.ts, case "check") which does the same comparison.

The actual problem (the only thing to fix)

When the catalog is stale, the failure surfaces as a raw assert.deepEqual mismatch — a wall of object diff that doesn't tell a contributor the fix is to run adapter-core triggers generate and commit. New contributors waste time on it.

Proposed solution (pick one)

  • Preferred: improve catalog-generator.test.ts so a mismatch throws a message like: Trigger catalog is out of date. Run \adapter-core triggers generate` and commit the updated catalog.generated.{ts,json}.` (keep the deep-equal as the check, just wrap the assertion with an actionable message.)
  • Or: add an explicit - run: npx adapter-core triggers check step to ci.yml before the test step — the check subcommand already prints a structured summary and can be given a clear failure message.

Either is fine; do not add both, and do not introduce a second source of truth or auto-commit bot.

Acceptance criteria

  • Intentionally make an adapter's events drift locally (or add a fake event), run the relevant check, and confirm the failure message names the exact remedy command and files.
  • npm test / Build & Test still green when the catalog is in sync.
  • No new redundant enforcement layer; no auto-generation/commit-back added.

Files

  • packages/core/tests/triggers/catalog-generator.test.ts (the existing drift assertion)
  • packages/core/src/triggers/catalog-generator.ts (generateTriggerCatalog, renderTriggerCatalogModule, writeTriggerCatalog({check}))
  • packages/core/src/cli.ts (triggers generate / triggers check)
  • .github/workflows/ci.yml

Related: #115 (missing adapter event coverage).

🤖 Generated with Claude Code

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions