Deployment status can be `deployment_queued`

[commiterate]

Description

For enum fields, githubkit uses a closed set of Python Literal strings. If GitHub adds a new enum value to an existing field or has one that isn't in any of its API models, githubkit will throw a validation error when calling response.parsed_data.

For example, GitHub's GetDeploymentStatus API (ref) has this successful response schema:

{
  "title": "GitHub Pages deployment status",
  "type": "object",
  "properties": {
    "status": {
      "type": "string",
      "description": "The current status of the deployment.",
      "enum": [
        "deployment_in_progress",
        "syncing_files",
        "finished_file_sync",
        "updating_pages",
        "purging_cdn",
        "deployment_cancelled",
        "deployment_failed",
        "deployment_content_failed",
        "deployment_attempt_error",
        "deployment_lost",
        "succeed"
      ]
    }
  }
}

The status, however, can also be deployment_queued which isn't in the model and thus not in the generated types.

https://github.com/yanyongyu/githubkit/blob/v0.15.3/githubkit/versions/v2026_03_10/models/group_0400.py

2026-04-29 19:47:49,282 [INFO] HTTP Request: GET https://api.github.com/repos/{owner}/{repo}/pages/deployments/{deployment ID} "HTTP/1.1 200 OK"
Traceback (most recent call last):
  # ...
  File ".../.venv/lib/python3.10/site-packages/githubkit/response.py", line 97, in parsed_data
    return type_validate_json(self._data_model, self.content)
  File ".../.venv/lib/python3.10/site-packages/githubkit/compat.py", line 57, in type_validate_json
    return TypeAdapter(type_).validate_json(data)
  File ".../.venv/lib/python3.10/site-packages/pydantic/type_adapter.py", line 492, in validate_json
    return self.validator.validate_json(
pydantic_core._pydantic_core.ValidationError: 2 validation errors for PagesDeploymentStatus
status.literal[<UNSET>]
  Input should be <UNSET> [type=literal_error, input_value='deployment_queued', input_type=str]
    For further information visit https://errors.pydantic.dev/2.12/v/literal_error
status.literal['deployment_in_progress','syncing_files','finished_file_sync','updating_pages','purging_cdn','deployment_cancelled','deployment_failed','deployment_content_failed','deployment_attempt_error','deployment_lost','succeed']
  Input should be 'deployment_in_progress', 'syncing_files', 'finished_file_sync', 'updating_pages', 'purging_cdn', 'deployment_cancelled', 'deployment_failed', 'deployment_content_failed', 'deployment_attempt_error', 'deployment_lost' or 'succeed' [type=literal_error, input_value='deployment_queued', input_type=str]
    For further information visit https://errors.pydantic.dev/2.12/v/literal_error

Essentially, githubkit isn't forwards-compatible with new enum values. This means existing code can suddenly break if GitHub introduces a new enum value.

While we can avoid validation today by doing response.json().get("status"), it's not as convenient as having class property access (e.g. response.parsed_data.status) and requires us to carefully choose between response.parsed_data and response.json() in different places.

It might make sense instead to change the type signature from Literal[...] to Literal[...] | str. That way, any LSPs and type checkers are still aware of possible literals but can still do mostly-exhaustive case checking.

Environment

• githubkit version:
  • 0.15.3
• Python version:
  • Python 3.10

[yanyongyu]

Hi, thanks for your valuable feedback.

githubkit always keeps in sync with upstream GitHub OpenAPI schema updates. We will re-generate models and release a new version promptly when the upstream schema changes.

For the long term, I will split githubkit's core runtime and schema definitions into two separate packages, allowing you to freely update and control the schema version you use.

[commiterate]

The concern here is less about the latest githubkit being out of sync and more of:

• Buggy upstream GitHub API models (like the example mentioned in the issue).
• Users using an old githubkit version against a newer GitHub API version (adds a new enum value, though this may be less of a concern if new enum values result in a new GitHub API version).

[yanyongyu]

I will also make a patch to schemas first to fix this bug.