MES-697: Validate Against GitHub Repos

[markovejnovic]

No description provided.

[markovejnovic]

/review

[mesa-dot-dev]

Mesa Description

This PR introduces validation against GitHub repositories, as outlined in MES-697. The primary goal is to ensure that repositories provided by the user exist and are accessible before attempting to use them within the system.

By querying the GitHub API, we now verify repository existence and user permissions early in the process, likely during user onboarding or when a new repository is configured. This change prevents downstream errors caused by invalid repository paths or insufficient access rights, providing immediate and clear feedback to the user. This improves the overall robustness and user experience of the system.

^{Description generated by Mesa. Update settings}

[mesa-dot-dev]

Performed full review of 793e402...2032555

Analysis

1. Dependency on lockfile accuracy is a single point of failure - any drift in versions or transitive dependencies will break all three workflows simultaneously.

2. The testing strategy relies heavily on Docker containerization and FUSE mounting, which creates infrastructure complexity that must be maintained alongside the core code.

3. There's no clear mechanism to ensure the repository matrix adequately covers the promised breadth of test scenarios.

4. The integration of multiple technologies (Rust binary, Python testing harness, Docker, FUSE, GitHub workflows) creates numerous integration points that could become fragile over time.

Tip

Help

Slash Commands:

• /review - Request a full code review
• /review latest - Review only changes since the last review
• /describe - Generate PR description. This will update the PR body or issue comment depending on your configuration
• /help - Get help with Mesa commands and configuration options

^{13 files reviewed | 4 comments | Edit Agent Settings • Read Docs}

[mesa-dot-dev]

pyproject.toml pins pytest-in-docker>=0.2.1, but the lock file resolves (and even records the requirement) as >=0.2.0 and locks version 0.2.0 here. uv sync --dev will refuse to install because the lock no longer satisfies the constraint from pyproject.toml, so every new CI workflow fails before tests run. Please regenerate uv.lock with a version ≥0.2.1 so the lock matches the declared requirement.

 • 

Prompt for Agent

Task: Address review feedback left on GitHub.
Repository: mesa-dot-dev/gitfs#23
File: uv.lock#L193
Action: Open this file location in your editor, inspect the highlighted code, and resolve the issue described below.

Feedback:
`pyproject.toml` pins `pytest-in-docker>=0.2.1`, but the lock file resolves (and even records the requirement) as `>=0.2.0` and locks version `0.2.0` here. `uv sync --dev` will refuse to install because the lock no longer satisfies the constraint from `pyproject.toml`, so every new CI workflow fails before tests run. Please regenerate `uv.lock` with a version ≥0.2.1 so the lock matches the declared requirement.

[mesa-dot-dev]

The dev dependency list that drives the lock omits pytest-xdist, even though pyproject.toml requires pytest-xdist>=3.5.0 and pytest is configured with addopts = "-n auto". As a result, uv sync --dev produces an environment without xdist and pytest immediately aborts with unrecognized arguments: -n auto. Please add pytest-xdist to the resolved packages (and to [package.dev-dependencies]) so the test jobs can actually start.

 • 

Prompt for Agent

Task: Address review feedback left on GitHub.
Repository: mesa-dot-dev/gitfs#23
File: uv.lock#L83
Action: Open this file location in your editor, inspect the highlighted code, and resolve the issue described below.

Feedback:
The dev dependency list that drives the lock omits `pytest-xdist`, even though `pyproject.toml` requires `pytest-xdist>=3.5.0` and pytest is configured with `addopts = "-n auto"`. As a result, `uv sync --dev` produces an environment without xdist and `pytest` immediately aborts with `unrecognized arguments: -n auto`. Please add `pytest-xdist` to the resolved packages (and to `[package.dev-dependencies]`) so the test jobs can actually start.

[mesa-dot-dev]

The metadata for the docker package is missing its websocket-client dependency. Testcontainers uses Docker’s websocket attach API, so importing docker will raise ModuleNotFoundError: No module named 'websocket' once the integration tests try to stream logs. Please regenerate the lock so websocket-client is modeled as a dependency; otherwise the docker SDK is unusable.

 • 

Prompt for Agent

Task: Address review feedback left on GitHub.
Repository: mesa-dot-dev/gitfs#23
File: uv.lock#L61
Action: Open this file location in your editor, inspect the highlighted code, and resolve the issue described below.

Feedback:
The metadata for the `docker` package is missing its `websocket-client` dependency. Testcontainers uses Docker’s websocket attach API, so importing `docker` will raise `ModuleNotFoundError: No module named 'websocket'` once the integration tests try to stream logs. Please regenerate the lock so `websocket-client` is modeled as a dependency; otherwise the docker SDK is unusable.

[mesa-dot-dev]

This suite is supposed to validate our mount layout against 10 GitHub repositories (per MES-697/branch name), but REPOS only lists two slugs. With such a small sample we still won’t catch layout regressions on most repo shapes (e.g., deep trees, symlinks, binaries). Please expand this list to the required set of 10 representative repositories so the new validation actually exercises the intended coverage.

 • 

Prompt for Agent

Task: Address review feedback left on GitHub.
Repository: mesa-dot-dev/gitfs#23
File: tests/test_directory_layout.py#L21
Action: Open this file location in your editor, inspect the highlighted code, and resolve the issue described below.

Feedback:
This suite is supposed to validate our mount layout against *10* GitHub repositories (per MES-697/branch name), but `REPOS` only lists two slugs. With such a small sample we still won’t catch layout regressions on most repo shapes (e.g., deep trees, symlinks, binaries). Please expand this list to the required set of 10 representative repositories so the new validation actually exercises the intended coverage.