DEV3-5281: Make checkout clone depth configurable across CI providers

[Pavel-tabnine]

What

Make clone depth configurable and consistently documented across all three CI providers (GitHub Actions, GitLab CI, Bitbucket Pipelines).

Why

The built-in review uses the gh / GitLab / Bitbucket REST APIs and does not need local git history — base_sha and head_sha are passed as explicit inputs. The previous fetch-depth: 0 recommendation was unnecessary overhead, especially on large monorepos. Users who legitimately need full history (custom prompt_override that inspects local git) now have a clean, documented opt-in.

Changes

• GitHub (GitHub/tabnine-review.yml): fetch-depth: ${{ vars.TABNINE_FETCH_DEPTH || 1 }} — override via repo variable TABNINE_FETCH_DEPTH.
• GitLab (GitLab/.gitlab-ci.yml): GIT_DEPTH: "20" default — override via CI/CD variable GIT_DEPTH.
• Bitbucket (Bitbucket/bitbucket-pipelines.yml): explicit clone.depth: 50 — platform does not support variable substitution, so override means editing the file.
• README: aligned two-sentence description pattern across all providers; added an Optional Variables table to the GitHub section for parity with GitLab/Bitbucket.
• action.yml: intentionally unchanged. actions/checkout runs in the caller workflow before the composite action, so the composite cannot control clone depth.

Defaults

All three defaults match each platform's native default, so existing users see no behavior change.

Jira

DEV3-5281

[Pavel-tabnine]

Tabnine PR Bot

[Low Risk]

What This PR Does
Makes git clone depth configurable (and consistently documented) across the GitHub, GitLab, and Bitbucket integrations, and removes the fetch-depth: 0 recommendation since the built-in review uses REST APIs with explicit base_sha/head_sha inputs and does not need local git history.

Assessment
Good to merge. The change is scoped cleanly to CI config + README, defaults are chosen to match each platform's native behavior (no regression for existing users), and the opt-in path for prompt_override workflows that inspect local git history is clearly documented. No correctness, security, or compatibility concerns.

Key Findings
None.

What Looks Good

• Consistent narrative across all three providers: "built-in review uses REST API → shallow is fine; set to full only if your custom prompt inspects local git."
• Defaults are platform-native (fetch-depth: 1 matches actions/checkout; clone.depth: 50 matches Bitbucket's implicit default), so existing users see no behavior change.
• Honest call-out that Bitbucket Pipelines does not support variable substitution in clone.depth, with a clear workaround (edit the file).
• README gains an Optional Variables table for the GitHub section, bringing it to parity with GitLab/Bitbucket.
• GitHub expression ${{ vars.TABNINE_FETCH_DEPTH || 1 }} handles unset/empty correctly and still allows "0" (full history) because non-empty strings are truthy.

Review metadata

• Risk tier: Tier 1
• Files reviewed: 4
• Inline comments posted: 0
• Highest severity: None
• Cross-repo analysis: skipped (Tier 1)

[yuvaltabnine]

After thinking about it some more, maybe we don't need to checkout at all.
If the workflow using the action has already checked out the repo, as most do, this is redundant.

I'm thinking not checking out at all and documenting it in the README. WDYT?

[Pavel-tabnine]

this is a standalone workflow that needs to pull the code. the composite action ( action.yml) doesn't include this