run ci for #8166#8227
Conversation
… output Add a `contractChanges` parameter to `updateGithubCheckRunForSchemaCheck` and pass `null` from all four call sites. This is groundwork for #6954 and introduces no behavior change yet; it mirrors the existing `failedContractCompositionCount` plumbing so contract data can be surfaced in the GitHub schema-check summary in a follow-up. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…all site Populate the new `contractChanges` parameter from `checkResult.state.contracts` at the successful schema-check call site, keeping only contracts that actually changed. The summary builder does not consume this yet, so behavior is unchanged; this isolates the call-site wiring for #6954. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A successful schema check on a composite/federation project could change only a contract (the core composed schema unchanged). The GitHub CI check summary was built solely from the core schema changes, so such a check was reported as "No changes" even though a contract had changed. Extract the success-branch title/summary logic into a pure, injectable helper (`buildSchemaCheckSuccessGithubOutput`) and feed it the per-contract changes plumbed through in the previous commits. "No changes" is now only reported when there are neither core nor contract changes; otherwise the summary lists the core changes followed by a per-contract section. Add unit tests covering: contract-only changes (no longer "No changes"), the genuine no-changes case, null inputs, empty contract change lists, core-only changes, and combined core + contract changes. Fixes #6954 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the GitHub CI schema-check summary to include contract changes, ensuring that contract-only changes are no longer incorrectly reported as 'No changes'. The logic for generating the successful schema-check output has been refactored into a pure, unit-tested function buildSchemaCheckSuccessGithubOutput. Feedback on these changes suggests using optional chaining when accessing checkResult.state.contracts to prevent potential runtime errors, and using an explicit length comparison in the contract changes filter for better consistency and strict TypeScript compatibility.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| contractChanges: | ||
| checkResult.state.contracts | ||
| ?.map(contract => ({ | ||
| contractName: contract.contractName, | ||
| changes: contract.schemaChanges?.all ?? [], | ||
| })) | ||
| .filter(contract => contract.changes.length > 0) ?? null, |
There was a problem hiding this comment.
The property checkResult.state is accessed directly as checkResult.state.contracts without optional chaining. In other parts of this method (such as lines 954, 962, and 963), checkResult.state is accessed using optional chaining (checkResult.state?.). To prevent potential runtime TypeError exceptions if state is null or undefined, please use optional chaining here as well.
contractChanges:
checkResult.state?.contracts
?.map(contract => ({
contractName: contract.contractName,
changes: contract.schemaChanges?.all ?? [],
}))
.filter(contract => contract.changes.length > 0) ?? null,| ) => string; | ||
| }): { title: string; summary: string; shortSummaryFallback: string } { | ||
| const coreChanges = input.changes ?? []; | ||
| const contractChanges = input.contractChanges?.filter(contract => contract.changes.length) ?? []; |
There was a problem hiding this comment.
Using contract.changes.length directly as a boolean predicate in .filter() is less explicit and can trigger linting errors under strict TypeScript configurations. For consistency with the implementation on line 961, please use an explicit comparison like contract.changes.length > 0.
const contractChanges = input.contractChanges?.filter(contract => contract.changes.length > 0) ?? [];
🚀 Snapshot Release (
|
| Package | Version | Info |
|---|---|---|
@graphql-hive/apollo |
0.48.1-alpha-20260716102027-2d173f31aa9974430d5f69787ff0daf263d59257 |
npm ↗︎ unpkg ↗︎ |
@graphql-hive/cli |
0.60.1-alpha-20260716102027-2d173f31aa9974430d5f69787ff0daf263d59257 |
npm ↗︎ unpkg ↗︎ |
@graphql-hive/core |
0.21.1-alpha-20260716102027-2d173f31aa9974430d5f69787ff0daf263d59257 |
npm ↗︎ unpkg ↗︎ |
@graphql-hive/envelop |
0.40.6-alpha-20260716102027-2d173f31aa9974430d5f69787ff0daf263d59257 |
npm ↗︎ unpkg ↗︎ |
@graphql-hive/yoga |
0.48.1-alpha-20260716102027-2d173f31aa9974430d5f69787ff0daf263d59257 |
npm ↗︎ unpkg ↗︎ |
hive |
11.2.2-alpha-20260716102027-2d173f31aa9974430d5f69787ff0daf263d59257 |
npm ↗︎ unpkg ↗︎ |
|
🐋 This PR was built and pushed to the following Docker images: Targets: Platforms: Image Tags: |
2 participants
Runs CI for #8166