Skip to content

Optionally factor BabelTest parsing out from GitHub fetching (futureproofing) #100

Description

@gaurav

Today, parsing BabelTest assertions out of an issue body lives on GitHubIssuesTestCases.get_test_issues_from_issue(), which is reached through a class that requires a GitHub token to construct. The parse logic itself (the {{BabelTest|...}} regex + the ```yaml babel_tests: block handling) needs no network or token — it just operates on the issue body string plus a little metadata.

Proposal (if/when needed): expose a pure parse entry point that doesn't require a GitHubIssuesTestCases / token, e.g. a free function or Assertion.from_issue_body(body, *, issue_id="", issue_url="", issue_state="") returning list[Assertion], and have get_test_issues_from_issue() delegate to it.

Priority: low / futureproofing. This is explicitly not expected to be used by anyone for a while — every current consumer (Babel pipeline, Babel Explorer) fetches test definitions from GitHub anyway, so PyGitHub is unavoidable and a separate parse path adds no value today. It's worth doing only if we later:

  • move off GitHub as the source of truth for tests, or
  • store tests in another format/location (e.g. a file, a database, or a different issue tracker),

at which point decoupling parsing from fetching would let those sources reuse the same assertion model without pulling in PyGitHub. Until then, keep it coupled (see the discussion on #67 / #96 — we deliberately did not build a GitHub-independent parsing layer in those PRs).

Filed as a follow-up to the library carve-out (#67).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions