BitBucket support - plan & discussion

[awrobel-gd]

Review notes

Assessment vs. the plan

PR16 does not ship the plan in docs/plans/workspace-repos/bitbucket-support.md. It ships a much narrower, separate plan the PR itself introduces — docs/plans/workspace-repos/bitbucket-pr1-commit-and-read.md — which explicitly scopes down to "credentials + runtime" and "auto-provisioning" only, and explicitly defers the full GitProvider ABC/registry package, CI/CD, and Server/DC to later PRs. That narrowing is reasonable and disclosed, but it means the two questions have to be answered against what actually shipped:

Can you commit code and get P10Y scores for a BitBucket workspace right now? No — five separate bugs block this, several of them in the common/default path:

1. resolve_github_auth_for_api_key_document's default-workspace-pool branch (github_auth.py:50-51) still hard-requires secrets.git_user_name_default to be truthy and returns it directly, instead of the active_git_user_default fallback this same PR introduced (and correctly uses two lines earlier for the per-key path). Since BitBucket onboarding deliberately never collects a username (access tokens auth as the fixed x-token-auth), any BitBucket deployment on the default pool with no GIT_USER_NAME_DEFAULT set — the exact flow the onboarding/plan promises ("paste one token, no username") — fails auth resolution before a single clone/commit happens.
2. Even where auth works, emit_workspace_config() writes p10y_repository_id: null for every BitBucket workspace, but init_firestore.py's WorkspaceConfig dataclass types that field as non-nullable int and raises in post_init — so feeding a BitBucket-provisioned --output-workspace-config file into init_firestore.py (its own docstring claims schema parity) crashes the seeding script.
3. Whether or not it crashes on the way in, any workspace that reaches Firestore with p10y_repository_id=None is permanently skipped by multi_workspace_estimation_p10y.py:105 and parallel_executor.py:305 — and there is no script or API anywhere in the repo to backfill that field once a human connects Compass to the BitBucket repo. "P10Y needs zero code change" (as the sub-plan claims) is true for the read path, but nothing in this PR ever populates the ID for BitBucket, so the read path never fires.
4. app_lifecycle.py:_init_platform_secrets only catches ValueError, but resolve_active_git_provider (now called unconditionally from _load_from_env) raises GitProviderResolutionError when neither token is configured — bypassing the existing DATABASE_TYPE=memory graceful-degradation fallback and hard-crashing local/dev boot in a state that previously started fine.
5. startup_validation.py's FR-5 health check still hardcodes GITHUB_TOKEN_DEFAULT/GIT_USER_NAME_DEFAULT as required for non-k8s firestore/emulator deployments, so a valid BitBucket-only deployment is reported unhealthy at startup even though it would actually work.

Does it set up for the future CI/CD (GHA→Pipelines) swap? Not well. create_generation_session_repos.py's main() threads ~12 separate if is_bitbucket: ... else: ... branches through owner selection, token selection, validation, and prints, rather than dispatching through the GitHostStrategy/registry the sibling full plan calls for. git_provider.py already models per-provider facts (default_git_user, sanitization_patterns) in a dataclass — but this script re-derives per-provider strings and flags ad hoc anyway. Bolting a DeployStrategy for BB Pipelines onto this shape means repeating the same two-way branch pattern in 3+ more places (workflow_steps.py, agents_claude_code.py, tool_usage.py) instead of registering one new strategy — a larger, riskier lift than if the minimal registry existed now.

Findings below, most severe first.

⏺ Code review(review · 6 findings)
● backend/app/services/github_auth.py:50 [correctness] — Default-workspace-pool auth resolution checks/returns raw git_user_name_default instead of the new active_git_user_default fallback, breaking BitBucket's no-username default-pool flow.
● backend/scripts/init_firestore.py:71 [correctness] — WorkspaceConfig.p10y_repository_id is typed non-nullable int and raises in __post_init__, but BitBucket's emit_workspace_config() now deliberately writes null for that field.
● backend/app/workflows/multi_workspace_estimation_p10y.py:105 [correctness] — Workspaces with p10y_repository_id=None (every BitBucket-provisioned workspace, permanently) are silently and permanently skipped from P10Y estimation with no backfill mechanism anywhere in the repo.
●backend/app/core/app_lifecycle.py:[correctness]— _init_platform_secrets only catches ValueError, but resolve_active_git_provider (now called unconditionally from _load_from_env) raises GitProviderResolutionError, bypassing the memory-mode graceful-degradation fallback and hard-crashing startup.
●backend/app/services/startup_validation.py:176[correctness] — FR-5 startup health check hardcodes GITHUB_TOKEN_DEFAULT/GIT_USER_NAME_DEFAULT as required for non-k8s firestore/emulator deployments, with no BitBucket alternative, so a valid BitBucket-only deployment is reported unhealthy.
●backend/scripts/create_generation_session_repo[altitude— Provider dispatch in main() is ~12 separate if is_bitbucket: ... else: ... branches instead of routing through the GitHostStrategy/registry the sibling full plan (docs/plans/workspace-repos/bitbucket-support.md) calls for, which will make the upcoming CI/CD (GHA→Pipelines) work harder, not easier.

These six findings answer both parts of the question directly:

Commit + P10Y MVP: not yet working. Five distinct, independently-triangulated bugs block it — the default-pool auth path breaks for BitBucket's no-username flow, the provisioning script emits JSON that crashes init_firestore.py, workspaces that do land in Firestore are permanently excluded from P10Y scoring with no backfill path, server startup can hard-crash in memory-mode dev with the new unhandled GitProviderResolutionError, and the health check misreports a valid BitBucket deployment as unhealthy.

Future CI/CD swap: not well-positioned. The provisioning script dispatches on is_bitbucket booleans threaded through ~12 branch points rather than the GitHostStrategy/registry pattern the full plan calls for, so each future CI/CD site (workflow_steps.py, agents_claude_code.py, tool_usage.py) will need its own hand-copied branch instead of one new strategy registration.