Your first migration

1. Read the invitation. Choose sharing.

A customer invitation needs no provider account or email sign-in. Provider operators use their separately provisioned workspace.

Check the exact SDK versions, supported edits and limitations before accepting. An expired, used or withdrawn invitation needs a new link from its operator.

Status sharing starts off. Repository and PR links each need separate consent. Save the once-shown token outside Git in an owner-only credential store; use it only in a separate reporting process or reporting-job secret.

2. Check your repository

• Working Python 3.11, Git and Docker. Declare every deployment runtime truthfully; the current target SDK needs Python 3.10+.
• One project with one root requirements.txt and exact public package pins, including pytest. No lockfiles, monorepos, private indexes, editable/VCS dependencies or custom builds.
• Explicit application source paths and a clean, committed Git checkout.
• A nonempty offline pytest suite that passes without production credentials.

The current reviewed pack supports three Deepgram generated-type binding changes and the exact 6.1.1 → 7.0.0 dependency update. It does not cover every v7 change. Ambiguous or unsupported usage stops with a blocker.

3. Install the checksum-pinned runner

In an empty directory outside your repository, download and review the installer, validate its pinned hash, then install. Use Python 3.11 explicitly:

curl --fail --location --proto '=https' --proto-redir '=https' 'https://github.com/1xollie/versionlane-releases/releases/download/v0.1.0/install_runner.py' --output install_runner.py
python3.11 -I -c "import hashlib,pathlib; assert hashlib.sha256(pathlib.Path('install_runner.py').read_bytes()).hexdigest() == 'f8d34e2fb95353531da9bba5d36be024fac5c4dde0b3809937f27456ceac2b30'"
python3.11 -I install_runner.py --wheel-url 'https://github.com/1xollie/versionlane-releases/releases/download/v0.1.0/versionlane_runner-0.1.0-py3-none-any.whl' --wheel-sha '11be7da53c9659f728531a18307c50a10e9b34b5f2dfe2e1c52d5dcf6eabf3ee' --requirements-url 'https://github.com/1xollie/versionlane-releases/releases/download/v0.1.0/runner-requirements.txt' --requirements-sha 'c5cd40659d70665166f97f5f3e35f9e63d7a038e47cbeeaa0ea5be231ad3405c' --destination ./versionlane-0.1.0
./versionlane-0.1.0/bin/python -I -m versionlane --help

Use that full Python path with -I -m versionlane for the commands shown after enrollment. Do not rely on a developer-installed command.

Using GitHub Actions? The reviewed downloads install the same released runner in fresh GitHub-hosted Ubuntu 24.04 jobs. Their setup supplies Python and Docker; no existing local installation is needed.

4. Save configuration and workflows

After accepting, download versionlane.toml, adjust source paths and deployment runtimes, and commit it. Review the supplied migration and status workflows, then commit them under .github/workflows. Add the optional PR-review workflow if you need the bounded ordinary-check process below.

No enrollment token belongs in these files. If choosing reporting, add VERSIONLANE_ENROLLMENT_TOKEN as a GitHub Actions secret, available only to reporting jobs.

Keep installation, verification artifacts and credentials outside the checkout.

5. Preview, then verify

The invitation supplies commands pinned to the actual campaign and pack hash. Local inspect executes no tests. verify runs independent fixtures and your separate baseline/candidate tests in restricted containers.

The migration workflow performs analysis and verification. Start it from your trusted default branch and explicitly request a draft PR. Reporting remains a separate opt-in.

Review changes.patch, verification.json and both JUnit files. Fixture checks and customer tests are separate. A verification failure blocks publication: repair the repository or decline the migration. Human edits to a migration branch are never overwritten.

6. Run ordinary checks. Review the PR.

Bot-created PRs may not trigger ordinary repository CI. Missing checks are not passing. Use your existing approved CI dispatch/reviewer process against the exact current PR head, without broader tokens.

Using the supplied optional review workflow

1. Open GitHub Actions → Versionlane PR review → Run workflow.
2. Select the trusted default branch. Enter the PR number and its current full 40-character head SHA.
3. Inspect the actual workflow result, JUnit file and review.json. Match tested_commit to the current PR head.
4. After any later edit, rerun required checks. The earlier result is stale.

The workflow runs your configured offline pytest suite at that exact commit in restricted containers. Its dispatch run belongs to the default branch; the evidence records the proposed commit it actually tested. Use existing required CI too. This narrow check does not replace integration or deployment tests.

Inspect every changed line and the reported limitations. A maintainer can mark the draft ready and accept through ordinary review, or close it to decline. Versionlane never merges automatically. A merged PR does not establish deployment.

7. Optional status sync

With your original consent, download receipt.json from the published-receipt artifact. In GitHub Settings → Secrets and variables → Actions → Variables, set VERSIONLANE_PR_STATE to:

{"receipt": <the entire receipt object>, "pr_url": "https://github.com/OWNER/REPOSITORY/pull/NUMBER"}

This contains bounded metadata, not a token. Keep the reporting credential in Secrets, never Variables. The reader checks the known PR with read-only access; a separate reporting job sends only consented metadata.

Run status sync explicitly. Failed reporting keeps its receipt for retry and does not change your local verification result. Ordinary CI results stay with you and are not uploaded to the provider. Last-received status is customer-reported, not independent attestation or proof of deployment.