The skills staleness notice detects CI by ci-info's rules; engine 0.2.2 - #224
Merged
Conversation
|
Warning Review limit reachedNext included review available in 33 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (8)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
commit: |
The engine already evaluates ci-info's vendor table against a caller-supplied env (detectCI in ci.ts); export it from the public surface so hosts can use the same answer. The shell's skills staleness notice previously checked only CI and GITHUB_ACTIONS, so CI systems that set neither — Jenkins (BUILD_ID), TeamCity (TEAMCITY_VERSION), Azure Pipelines (TF_BUILD) — got the notice line in their logs. It now asks detectCI, and the suppression tests cover a vendor that sets no CI variable. Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
pnpm bump-cli-engine-version patch. Engine 0.2.1 published with the c12 resolution fix before this change landed, and published versions are immutable. The families have not released against 0.2.1 yet, so the transition exceptions simply move to 0.2.2 — the family releases peer 0.2.2 and skip 0.2.1 entirely. Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
wmadden-electric
force-pushed
the
claude/engine-detectci-export
branch
from
August 24, 2026 13:20
ea3cc32 to
f1196b1
Compare
wmadden
approved these changes
Aug 24, 2026
This was referenced Aug 24, 2026
Merged
wmadden
pushed a commit
that referenced
this pull request
Aug 25, 2026
## At a glance ```bash # before this PR merges npm install prisma # -> 7.9.1 (Prisma 7) npm install prisma@next # -> 8.0.0-rc.9 # after this PR merges npm install prisma # -> 8.0.0-rc.10 (the unified v8 CLI) ``` ## The decision We are cutting the bare `prisma` npm name over to the v8 line. Until now, every 8.0.0-rc release published under the `next` dist-tag and `latest` kept serving Prisma 7, so nobody landed on v8 without asking for it. The operator ruled today (2026-08-25) that the RC line is ready to be what a bare `npm install prisma` gets. The version number does not change meaning: we stay on `8.0.0-rc.N` (this release is rc.10), and GitHub Releases remain marked pre-release. Only the dist-tag policy moves. ## How the flip actually happens In this repo, merging a version-bump PR is the act that publishes: the push to `main` carries a changed root version, and the publish workflow ships it under the tag `releaseDistTag()` returns. This PR widens that function so every release — RC or stable — publishes under `latest`. **Merging this PR is therefore the cutover itself**: it bumps rc.9 → rc.10 and the resulting publish moves `latest` on `prisma` and `@prisma/cli` in one deliberate, reviewable act. ## What rc.10 ships (since rc.9) - Config files evaluate correctly when the CLI is reached through pnpm symlink layouts that are not realpath'd (#222) — previously every config-reading command failed with `CLI.CONFIG_UNREADABLE` in those setups. - The engine's CI detector is exported and the skills staleness notice uses it, so Jenkins/TeamCity/Azure pipelines stop seeing the notice in their logs (#224). - The `prisma init` scaffold fixes (#225). - Current command-family releases, both peering the exact engine this repo ships (`@prisma/cli-engine@0.2.3`), so one engine resolves per install and the conformance exception list is empty again: `@prisma/composer-cli@0.14.0` and `@prisma/orm-toolchain@8.0.0-rc.7` (which carries the PostgreSQL temporal-codec representations and the `limit`/`offset` pagination rename). ## What happens to the `next` tag and to v7 users - `next` is retired: the publish path no longer moves it, and `scripts/cutover-dist-tags.sh` (operator-run) removes it from all three names and fixes the engine's stale tags. Text that says `prisma@next` should move to plain `prisma` — after this merge they resolve the same thing anyway, until the tag is removed. - Existing v7 installs are untouched: lockfiles pin resolved versions, and `prisma@7.9.1` stays installable by version. The v7 train's new publish home (`prisma7`) is being handled separately and does not block this. ## Alternatives considered - **A one-off `workflow_dispatch` with `dist-tag: latest`** — moves `latest` once, but every subsequent RC release would publish under `next` again and leave `latest` stale on rc.10. The widened rule makes the routine release path keep `latest` current. - **Waiting for stable `8.0.0`** — the rollout plan always left the flip timing to an operator judgement after an RC soak, not to the stable release; the operator ruled the soak is over. - **Keeping `next` synced to `latest`** — considered so existing `prisma@next` instructions would keep resolving the newest release, and dropped: re-pointing a tag on an already-published version cannot authenticate over OIDC, and npm's granular tokens go no narrower than package write — a standing sync would mean a standing publish-capable token, defeating the repo's OIDC-only invariant. Retiring the tag is the honest alternative. ## Verification Script tests green (33/0 on determine-version-utils). Conformance with the empty exception list: **5 subjects checked, nothing to report**, on both the release and dev channels. Lint and the CLI/engine suites green. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
birhantprkc
pushed a commit
to birhantprkc/prisma
that referenced
this pull request
Aug 25, 2026
…ne@0.2.2 (prisma#30111) prisma-cli published `@prisma/cli-engine@0.2.2`: config evaluation works through pnpm symlink layouts that are not realpath'd (prisma/prisma-cli#222) and the engine's CI detector is exported (prisma/prisma-cli#224). The registry's 0.2.0 predates both; 0.2.1 is skipped — no family released against it. `@prisma/orm-toolchain` declares the engine as an exact peer, so it must release against the engine version the `prisma` bin will ship. - Every `@prisma/cli-engine` reference moves 0.2.0 → 0.2.2 (manifests, fixtures, examples, the init-journey harness literal). - `pnpm bump-version`: 8.0.0-rc.5 → 8.0.0-rc.6, stamped across the workspace. - Release notes at `docs/releases/v8.0.0-rc.6.md` (`check:release-notes --mode pr` passes) plus the matching `CHANGELOG.md` entry, covering prisma#30096 and prisma#30097 — the two PRs merged since rc.5 — and the engine move. - `check:upgrade-coverage` passes in both modes. Merging publishes the release under `latest`, which unblocks the prisma-cli PR that pins it and removes the engine-transition exceptions. The composer half of the train is prisma/composer#256. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Bundled `prisma-8` skills and upgrade guidance are now included in ORM package tarballs. * Skill setup is now handled through `prisma init`. * **Breaking Changes** * PostgreSQL temporal columns now use explicit `Temporal` or text representations instead of `Date`. * `prisma orm init` no longer installs skills or supports `--skip-skills`. * **Documentation** * Added `8.0.0-rc.6` release notes and upgrade instructions, including contract artifact updates and temporal migration examples. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The per-command skills staleness notice suppressed itself only under
CIorGITHUB_ACTIONS, so CI systems that set neither variable — Jenkins (BUILD_ID), TeamCity (TEAMCITY_VERSION), Azure Pipelines (TF_BUILD) — got the notice line in their logs.Changes
detectCI(env)— ci-info's vendor table evaluated against a caller-supplied env, neverprocess.env— is now exported from the package's public surface (it already backedresolveIsCI; the export-surface inventory test is updated).detectCI(runtime.env). TheGITHUB_ACTIONSspecial case is gone (GitHub Actions setsCI=true, and the vendor table covers it regardless).CIcase and addsTEAMCITY_VERSION— a vendor the old check missed.pnpm bump-cli-engine-version patch): the export surface changed, and 0.2.1 already published (immutable) from Config evaluation works through pnpm symlink layouts; engine 0.2.1 #222. The families have not released against 0.2.1 yet, so the transition exceptions from Config evaluation works through pnpm symlink layouts; engine 0.2.1 #222 move to 0.2.2 — the family releases peer 0.2.2 and skip 0.2.1 entirely.With this, all three CI-detection surfaces (the ORM's
is-ci.tswrapping ci-info, the engine, and the shell's notice) derive from ci-info's data.Verification
Engine suite 35 files pass; CLI suite 61 files pass (including the new TEAMCITY case);
pnpm run conformance: 0 failing, the transition mismatches suppressed by the recorded exceptions;check-engine-version.mjs origin/main: 0.2.2 consistent; typecheck green.After merge
Same train as #222, now targeting 0.2.2: main publishes
@prisma/cli-engine@0.2.2→ composer and prisma/prisma release peering 0.2.2 → a follow-up PR here pins those releases and empties the exception list.🤖 Generated with Claude Code