Skip to content

feat(apps): add Testiny connector with a raw-header auth strategy - #466

Open
biztex wants to merge 1 commit into
onecli:mainfrom
biztex:feat/testiny-connector
Open

feat(apps): add Testiny connector with a raw-header auth strategy#466
biztex wants to merge 1 commit into
onecli:mainfrom
biztex:feat/testiny-connector

Conversation

@biztex

@biztex biztex commented Jul 30, 2026

Copy link
Copy Markdown

I have read the CONTRIBUTING.md file.

YES

What kind of change does this PR introduce?

Feature — a new app connector, plus a small gateway auth-strategy addition it needs. Closes #422.

What is the current behavior?

Testiny is not in the app catalog. Its REST API (app.testiny.io/api/v1) authenticates with an API key sent raw in the X-Api-Key header — no Bearer prefix — and no existing AuthStrategy (Bearer / BasicXAccessToken / None) can express that, so the gateway has no way to inject a Testiny credential today.

What is the new behavior?

Gateway: a generic AuthStrategy::Header { name } variant that injects the raw credential into a provider-named header. It slots in beside the existing strategies (both injection match sites), with unit tests (providers_for_testiny_host, testiny_uses_raw_x_api_key_header). This also unblocks other raw-header providers — e.g. MantisHub (#298), whose API takes the raw token in Authorization, would just be Header { name: "authorization" }.

A Testiny connector following the existing api_key shape (cf. Resend / Fly.io / Cloudflare):

  • Connection: API key stored encrypted, injected as X-Api-Key on app.testiny.io. Metadata is best-effort from GET /api/v1/project (first visible project name); non-fatal.
  • Permission catalog: Testiny is uniform CRUD under /api/v1/<entity>, so the catalog has per-entity read and write tools for projects, test cases + folders, test runs (incl. recording results), test plans, milestones, and comments — plus the POST /api/v1/<entity>/find query endpoints as a read tool. The finds are reads that travel as POST, so the GET-only read wildcard is deliberately not advertised as a complete umbrella (same situation as Jira's JQL search, per the wildcardCoversGroup docs); the write wildcard (POST/PUT/PATCH/DELETE /api/v1/*) is a true superset — over-gating the POST finds is the fail-closed direction. Verified by the wildcard-coverage suites (180 apps tests pass locally).
  • Dashboard: catalog card (Development category) with light/dark icons.

Additional context

  • The reporter's use case in App request: Testiny #422 — "short summary of nightly test cases, to see if something is broken" — needs exactly read_testruns + search_entities, which selective mode can grant without any write access.
  • Icon note: Testiny isn't in Simple Icons, so the icon is a neutral clipboard-check mark in the same 24×24 monochrome style as the other catalog icons — happy to swap in an official asset if you have one with clear licensing.

Testiny's REST API (app.testiny.io/api/v1) authenticates with an API
key sent raw in the X-Api-Key header - no Bearer prefix - which no
existing AuthStrategy covers. Add a generic Header variant that injects
the credential into a provider-named header, and use it for the Testiny
provider. The variant also unblocks other raw-header providers (e.g.
MantisHub's raw Authorization token, onecli#298).

The permission catalog mirrors Testiny's uniform CRUD: per-entity read
and write tools for projects, test cases and folders, test runs, test
plans, milestones, and comments, plus the POST /find query endpoints as
a read tool. The finds travel as POST, so the GET-only read wildcard is
deliberately not a superset (Jira JQL precedent); the write wildcard
gates every mutating method under /api/v1/* and is a true superset.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

App request: Testiny

1 participant