Skip to content

Automate the upstream protocol refresh #29

Description

@Agash

Nothing detects a new obs-websocket release. protocol.json is refreshed by hand, and the 5.7 refresh is what silently moved canvasUuid into generated constructors and bound an argument to the wrong parameter.

Shape

On a new upstream release: fetch protocol.json, regenerate with -p:ObsCodegenForceRegeneration=true, build every target framework, run the tests, and open a PR with the diff.

Two things the pipeline has to get right that a normal build does not:

  • Force regeneration. Codegen is incremental on protocol.json, so an emitter change alone does not regenerate. A refresh job that skips the flag can produce a green build against stale generated code.
  • Run the live suite. run-transport-tests against a real OBS on both transports is the only thing that catches a mis-mapped payload. OBSWSGEN010 only catches an un-mapped one. That needs an OBS in CI, or a manual gate on the generated PR.

Not proposing a separate conformance suite

A suite asserting "every protocol request has a generated method" would re-test a foreach over protocol.Requests; the emitter iterates the definition directly, so that property holds by construction. The interpretation rules that genuinely could drift already fail the build: OBSWSGEN010 (unmapped array), 012 (unclassified number), 013 (whole number with a fractional restriction), 014 (declared string enum with no field mapped), plus the formatter coverage tests.

The gap is the refresh being manual, not the checks being absent.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions