Enforce code quality — snake_case renames, linting, type checking, and CI pipeline

[domino-blake]

Link to JIRA

(no ticket — internal housekeeping)

What issue does this pull request solve?

The codebase had no automated quality gates on PRs: no CI, no enforced formatting, 38 mypy type errors, and public API parameters that mixed camelCase and snake_case (violating PEP 8). Contributors could merge broken or inconsistently styled code with no automated feedback.

What is the solution?

API cleanup (backward-compatible)

• Renamed 18 camelCase public API parameters to snake_case across runs_start, runs_start_blocking, run_stop, runs_status, get_run_log, runs_stdout, files_list, endpoint_publish, app_publish, and app_unpublish
• Old names still work — each emits a DeprecationWarning via a **kwargs shim pointing callers to the new name
• app_publish() also gains branch and commit_id parameters to launch from a specific git ref, and an explicit app_id parameter

Linting & type safety

• Added scripts/check_snake_case.py — an AST-based checker that prevents new camelCase parameter names from being introduced
• Resolved all 38 pre-existing mypy errors across 9 files (implicit Optional, wrong return types, invalid type annotations, any vs Any, etc.)
• Resolved all flake8, isort, and black formatting violations
• Updated all pre-commit hook versions to current releases; added check-snake-case, mypy, and black to the hook set
• Added pyproject.toml with isort/black config to ensure they agree on formatting

CI / CD

• Added .github/workflows/ci.yml with three gating jobs: lint (black, isort, flake8, snake_case), typecheck (mypy), and test (pytest matrix across Python 3.10/3.11/3.12 with coverage upload)
• Rewrote tox.ini to run the full test suite across all supported Python versions (previously only ran 2 files on Python 3.9)

Testing

• 177 unit tests pass, 55 skipped (require live Domino deployment)

• 18 new tests in tests/test_deprecations.py cover every renamed parameter — both that the warning is raised with the old name and that the new name is accepted silently

• All pre-commit checks pass locally: check-snake-case, flake8, isort, black, mypy

• CI jobs validated locally by running each step in sequence

• Unit test(s)

Pull Request Reminders

• Has the changelog been updated
• Has relevant documentation been updated?
• Does the code follow the Python Style Guide
• Are the existing unit tests still passing?
• Have new unit tests been added to cover any changes to the code?

[ddl-ebrown]

Can we split this PR apart into 3 different PRs?

It has a mixture of changes which fall into different categories that should be separated to make it easier to review and merge:

• Entirely backwards compatible / perfectly safe to go in together and uncontroversial --- changes around linting, type safety and things that are actual errors can all be grouped together with the CI changes that check for these problems. Anywhere that linters required material changes to APIs should have inline exclusions / ignores rather than changes to comply with the linter.
• Additions to existing APIs (like app_publish). New, optional params should be fairly easy to introduce, but don't belong with all of the other code quality changes. Let's isolate those - those should be pretty uncontroversial as well as they're backwards compatible if done properly.
• Parameter renaming / consistency - these are technically breaking, even though it appears an effort was made to allow APIs to accept old parameter names. There will probably be a bit more discussion around that and it's best that these changes are grouped together for the sake of logically grouping / review and making it easier to revert later if necessary.

Thanks!

[ddl-ebrown]

Left a comment about breaking this up more sensibly

[domino-blake]

Closing this out in favour of #265 #266 #267