From 21f16ec5739954ba7ee6c921d3213c351aa6d398 Mon Sep 17 00:00:00 2001 From: Jamie <2119834+jamieQ@users.noreply.github.com> Date: Mon, 27 Jul 2026 11:37:42 -0700 Subject: [PATCH 1/5] docs(preprod): Document skipped status checks Explain how CI workflows can satisfy required checks when they intentionally skip artifact uploads. Refs EME-1218 --- .../size-analysis/integrating-into-ci.mdx | 40 +++++++++++++++++++ .../product/snapshots/integrating-into-ci.mdx | 40 +++++++++++++++++++ 2 files changed, 80 insertions(+) diff --git a/docs/product/size-analysis/integrating-into-ci.mdx b/docs/product/size-analysis/integrating-into-ci.mdx index 5a3c10e2d3eeb..a7ac17220f39b 100644 --- a/docs/product/size-analysis/integrating-into-ci.mdx +++ b/docs/product/size-analysis/integrating-into-ci.mdx @@ -77,6 +77,46 @@ Confirm that builds uploaded from this workflow have the correct `sha` and `base For more options on controlling which builds get processed for Size Analysis, see [Configuring Size Analysis Uploads](/product/size-analysis/#configuring-size-analysis-uploads). +### Skip the Status Check When No Build Is Uploaded + +Your team may require a Size Analysis check on every pull request, even when some CI workflows don't produce a build artifact. For example, a pull request that changes only documentation or other files that don't affect the app binary may not need a new build. In these cases, use the skip endpoint to create a neutral check for the pull request's head commit so that it can merge without an unnecessary build. + + + The upload and skip paths should be mutually exclusive. Each workflow should + either upload a build or mark the check as skipped. Only use the skip endpoint + when the workflow deliberately omits the upload; don't use it to turn a + build, test, or upload failure into a neutral check. + + +The example below assumes an earlier path-filtering step with an ID of `changes` sets a `should_upload` output. Use the same condition for your upload step and the inverse condition for the skip step so that only one runs. Reuse the `SENTRY_AUTH_TOKEN` configured for uploads and store it as an [encrypted GitHub Actions secret](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions). + +```yml {filename:sentry_size_analysis_pull_request.yml} +- name: Mark Size Analysis as skipped + if: github.event_name == 'pull_request' && steps.changes.outputs.should_upload == 'false' + env: + SENTRY_AUTH_TOKEN: ${{ secrets.SENTRY_AUTH_TOKEN }} + SENTRY_ORG: ${{ secrets.SENTRY_ORG }} + SENTRY_PROJECT: ${{ secrets.SENTRY_PROJECT }} + HEAD_SHA: ${{ github.event.pull_request.head.sha }} + run: | + jq -n \ + --arg sha "$HEAD_SHA" \ + --arg repository "$GITHUB_REPOSITORY" \ + '{sha: $sha, repository: $repository, provider: "github"}' | + curl --fail-with-body \ + --request POST \ + --header "Authorization: Bearer $SENTRY_AUTH_TOKEN" \ + --header "Content-Type: application/json" \ + --data-binary @- \ + "https://sentry.io/api/0/projects/$SENTRY_ORG/$SENTRY_PROJECT/preprod/size-analysis/status-checks/skip/" +``` + +The request returns an empty `200 OK` response. Set `provider` to `github` for GitHub.com or `github_enterprise` for GitHub Enterprise. + + + This endpoint is experimental and may change. + + 5. Confirm the status check appears After configuring both workflows and sending the correct metadata, the status check should appear on every commit: diff --git a/docs/product/snapshots/integrating-into-ci.mdx b/docs/product/snapshots/integrating-into-ci.mdx index 89e3d37a131b6..6b37de2c47719 100644 --- a/docs/product/snapshots/integrating-into-ci.mdx +++ b/docs/product/snapshots/integrating-into-ci.mdx @@ -53,6 +53,46 @@ jobs: Confirm that snapshots uploaded on `push` have the correct `head-sha` and no `base-sha` set, and that snapshots uploaded on `pull_request` have both `head-sha` and `base-sha` set. +### Skip the Status Check When No Snapshots Are Uploaded + +Your team may require a Snapshot Testing check on every pull request, even when some CI workflows don't produce snapshots. For example, a pull request that changes only documentation or other files that don't affect the rendered UI may not need new snapshots. In these cases, use the skip endpoint to create a neutral check for the pull request's head commit so that it can merge without generating unnecessary snapshots. + + + The upload and skip paths should be mutually exclusive. Each workflow should + either upload snapshots or mark the check as skipped. Only use the skip + endpoint when the workflow deliberately omits the upload; don't use it to + turn a build, test, or upload failure into a neutral check. + + +The example below assumes an earlier path-filtering step with an ID of `changes` sets a `should_upload` output. Use the same condition for your upload step and the inverse condition for the skip step so that only one runs. Reuse the `SENTRY_AUTH_TOKEN` configured for uploads and store it as an [encrypted GitHub Actions secret](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions). + +```yml {filename:sentry_snapshots.yml} +- name: Mark Snapshot Testing as skipped + if: github.event_name == 'pull_request' && steps.changes.outputs.should_upload == 'false' + env: + SENTRY_AUTH_TOKEN: ${{ secrets.SENTRY_AUTH_TOKEN }} + SENTRY_ORG: ${{ secrets.SENTRY_ORG }} + SENTRY_PROJECT: ${{ secrets.SENTRY_PROJECT }} + HEAD_SHA: ${{ github.event.pull_request.head.sha }} + run: | + jq -n \ + --arg sha "$HEAD_SHA" \ + --arg repository "$GITHUB_REPOSITORY" \ + '{sha: $sha, repository: $repository, provider: "github"}' | + curl --fail-with-body \ + --request POST \ + --header "Authorization: Bearer $SENTRY_AUTH_TOKEN" \ + --header "Content-Type: application/json" \ + --data-binary @- \ + "https://sentry.io/api/0/projects/$SENTRY_ORG/$SENTRY_PROJECT/preprod/snapshots/status-checks/skip/" +``` + +The request returns an empty `200 OK` response. Set `provider` to `github` for GitHub.com or `github_enterprise` for GitHub Enterprise. + + + This endpoint is experimental and may change. + + 4. Confirm the status check appears After configuring the workflow, a **Snapshot Testing** status check will appear on every pull request. From 5d58ff2ca141b8b161e190c8f76646e2cf8a3f36 Mon Sep 17 00:00:00 2001 From: Jamie <2119834+jamieQ@users.noreply.github.com> Date: Mon, 27 Jul 2026 12:02:24 -0700 Subject: [PATCH 2/5] docs(preprod): Move skip guidance outside setup flow Keep the numbered integration steps focused on the primary setup path and present optional status-check skipping as a separate section. Refs EME-1218 --- .../size-analysis/integrating-into-ci.mdx | 26 +++++++++---------- .../product/snapshots/integrating-into-ci.mdx | 18 ++++++------- 2 files changed, 22 insertions(+), 22 deletions(-) diff --git a/docs/product/size-analysis/integrating-into-ci.mdx b/docs/product/size-analysis/integrating-into-ci.mdx index a7ac17220f39b..a1d59c7e06d0b 100644 --- a/docs/product/size-analysis/integrating-into-ci.mdx +++ b/docs/product/size-analysis/integrating-into-ci.mdx @@ -77,7 +77,19 @@ Confirm that builds uploaded from this workflow have the correct `sha` and `base For more options on controlling which builds get processed for Size Analysis, see [Configuring Size Analysis Uploads](/product/size-analysis/#configuring-size-analysis-uploads). -### Skip the Status Check When No Build Is Uploaded +5. Confirm the status check appears + +After configuring both workflows and sending the correct metadata, the status check should appear on every commit: + +![Example Status Check =600x](./images/status-check-inline.png) + +6. View the detailed breakdown + +Clicking on the "Details" button above should bring you to a more detailed breakdown of the changes. + +![Example Status Check](./images/status-check.png) + +## Skip the Status Check When No Build Is Uploaded Your team may require a Size Analysis check on every pull request, even when some CI workflows don't produce a build artifact. For example, a pull request that changes only documentation or other files that don't affect the app binary may not need a new build. In these cases, use the skip endpoint to create a neutral check for the pull request's head commit so that it can merge without an unnecessary build. @@ -117,18 +129,6 @@ The request returns an empty `200 OK` response. Set `provider` to `github` for G This endpoint is experimental and may change. -5. Confirm the status check appears - -After configuring both workflows and sending the correct metadata, the status check should appear on every commit: - -![Example Status Check =600x](./images/status-check-inline.png) - -6. View the detailed breakdown - -Clicking on the "Details" button above should bring you to a more detailed breakdown of the changes. - -![Example Status Check](./images/status-check.png) - ## Configuring Status Check Rules By default, status checks appear as neutral and won't block pull requests. You can configure rules to automatically fail status checks when size thresholds are exceeded. diff --git a/docs/product/snapshots/integrating-into-ci.mdx b/docs/product/snapshots/integrating-into-ci.mdx index 6b37de2c47719..19da372dc66af 100644 --- a/docs/product/snapshots/integrating-into-ci.mdx +++ b/docs/product/snapshots/integrating-into-ci.mdx @@ -53,7 +53,15 @@ jobs: Confirm that snapshots uploaded on `push` have the correct `head-sha` and no `base-sha` set, and that snapshots uploaded on `pull_request` have both `head-sha` and `base-sha` set. -### Skip the Status Check When No Snapshots Are Uploaded +4. Confirm the status check appears + +After configuring the workflow, a **Snapshot Testing** status check will appear on every pull request. + +![Example of a failing Snapshot Testing status check on a pull request](./img/failing_status_check_example.png) + +For details on the review and approval flow, see [Reviewing Snapshots](/product/snapshots/reviewing-snapshots/). + +## Skip the Status Check When No Snapshots Are Uploaded Your team may require a Snapshot Testing check on every pull request, even when some CI workflows don't produce snapshots. For example, a pull request that changes only documentation or other files that don't affect the rendered UI may not need new snapshots. In these cases, use the skip endpoint to create a neutral check for the pull request's head commit so that it can merge without generating unnecessary snapshots. @@ -93,14 +101,6 @@ The request returns an empty `200 OK` response. Set `provider` to `github` for G This endpoint is experimental and may change. -4. Confirm the status check appears - -After configuring the workflow, a **Snapshot Testing** status check will appear on every pull request. - -![Example of a failing Snapshot Testing status check on a pull request](./img/failing_status_check_example.png) - -For details on the review and approval flow, see [Reviewing Snapshots](/product/snapshots/reviewing-snapshots/). - ## Troubleshooting ### Status Check Not Appearing From 2a08d9945af3826b70d5e58b6a56884ce1faa3d6 Mon Sep 17 00:00:00 2001 From: Jamie <2119834+jamieQ@users.noreply.github.com> Date: Mon, 27 Jul 2026 13:01:32 -0700 Subject: [PATCH 3/5] docs(preprod): Simplify skipped check warning Refs EME-1218 --- docs/product/size-analysis/integrating-into-ci.mdx | 4 +--- docs/product/snapshots/integrating-into-ci.mdx | 4 +--- 2 files changed, 2 insertions(+), 6 deletions(-) diff --git a/docs/product/size-analysis/integrating-into-ci.mdx b/docs/product/size-analysis/integrating-into-ci.mdx index a1d59c7e06d0b..352930941fa64 100644 --- a/docs/product/size-analysis/integrating-into-ci.mdx +++ b/docs/product/size-analysis/integrating-into-ci.mdx @@ -95,9 +95,7 @@ Your team may require a Size Analysis check on every pull request, even when som The upload and skip paths should be mutually exclusive. Each workflow should - either upload a build or mark the check as skipped. Only use the skip endpoint - when the workflow deliberately omits the upload; don't use it to turn a - build, test, or upload failure into a neutral check. + either upload a build or mark the check as skipped. The example below assumes an earlier path-filtering step with an ID of `changes` sets a `should_upload` output. Use the same condition for your upload step and the inverse condition for the skip step so that only one runs. Reuse the `SENTRY_AUTH_TOKEN` configured for uploads and store it as an [encrypted GitHub Actions secret](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions). diff --git a/docs/product/snapshots/integrating-into-ci.mdx b/docs/product/snapshots/integrating-into-ci.mdx index 19da372dc66af..605b02e322e3a 100644 --- a/docs/product/snapshots/integrating-into-ci.mdx +++ b/docs/product/snapshots/integrating-into-ci.mdx @@ -67,9 +67,7 @@ Your team may require a Snapshot Testing check on every pull request, even when The upload and skip paths should be mutually exclusive. Each workflow should - either upload snapshots or mark the check as skipped. Only use the skip - endpoint when the workflow deliberately omits the upload; don't use it to - turn a build, test, or upload failure into a neutral check. + either upload snapshots or mark the check as skipped. The example below assumes an earlier path-filtering step with an ID of `changes` sets a `should_upload` output. Use the same condition for your upload step and the inverse condition for the skip step so that only one runs. Reuse the `SENTRY_AUTH_TOKEN` configured for uploads and store it as an [encrypted GitHub Actions secret](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions). From 730a742cb1919969064fc026ccdaae0bba8e18ee Mon Sep 17 00:00:00 2001 From: Jamie <2119834+jamieQ@users.noreply.github.com> Date: Mon, 27 Jul 2026 13:17:10 -0700 Subject: [PATCH 4/5] docs(preprod): Rename skipped check examples Refs EME-1218 --- docs/product/size-analysis/integrating-into-ci.mdx | 2 +- docs/product/snapshots/integrating-into-ci.mdx | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/product/size-analysis/integrating-into-ci.mdx b/docs/product/size-analysis/integrating-into-ci.mdx index 352930941fa64..6e936810cfc49 100644 --- a/docs/product/size-analysis/integrating-into-ci.mdx +++ b/docs/product/size-analysis/integrating-into-ci.mdx @@ -100,7 +100,7 @@ Your team may require a Size Analysis check on every pull request, even when som The example below assumes an earlier path-filtering step with an ID of `changes` sets a `should_upload` output. Use the same condition for your upload step and the inverse condition for the skip step so that only one runs. Reuse the `SENTRY_AUTH_TOKEN` configured for uploads and store it as an [encrypted GitHub Actions secret](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions). -```yml {filename:sentry_size_analysis_pull_request.yml} +```yml {filename:skip_status_checks_example.yml} - name: Mark Size Analysis as skipped if: github.event_name == 'pull_request' && steps.changes.outputs.should_upload == 'false' env: diff --git a/docs/product/snapshots/integrating-into-ci.mdx b/docs/product/snapshots/integrating-into-ci.mdx index 605b02e322e3a..91976d5d06881 100644 --- a/docs/product/snapshots/integrating-into-ci.mdx +++ b/docs/product/snapshots/integrating-into-ci.mdx @@ -72,7 +72,7 @@ Your team may require a Snapshot Testing check on every pull request, even when The example below assumes an earlier path-filtering step with an ID of `changes` sets a `should_upload` output. Use the same condition for your upload step and the inverse condition for the skip step so that only one runs. Reuse the `SENTRY_AUTH_TOKEN` configured for uploads and store it as an [encrypted GitHub Actions secret](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions). -```yml {filename:sentry_snapshots.yml} +```yml {filename:skip_status_checks_example.yml} - name: Mark Snapshot Testing as skipped if: github.event_name == 'pull_request' && steps.changes.outputs.should_upload == 'false' env: From c27010b93983c676a816bac6c08d22565564a06e Mon Sep 17 00:00:00 2001 From: Jamie <2119834+jamieQ@users.noreply.github.com> Date: Fri, 31 Jul 2026 09:05:51 -0500 Subject: [PATCH 5/5] docs(preprod): Link skipped status check API docs Remove the outdated experimental notices now that the endpoints are public. Refs EME-1218 --- docs/product/size-analysis/integrating-into-ci.mdx | 8 ++------ docs/product/snapshots/integrating-into-ci.mdx | 8 ++------ 2 files changed, 4 insertions(+), 12 deletions(-) diff --git a/docs/product/size-analysis/integrating-into-ci.mdx b/docs/product/size-analysis/integrating-into-ci.mdx index 6e936810cfc49..1119d8f270779 100644 --- a/docs/product/size-analysis/integrating-into-ci.mdx +++ b/docs/product/size-analysis/integrating-into-ci.mdx @@ -91,7 +91,7 @@ Clicking on the "Details" button above should bring you to a more detailed break ## Skip the Status Check When No Build Is Uploaded -Your team may require a Size Analysis check on every pull request, even when some CI workflows don't produce a build artifact. For example, a pull request that changes only documentation or other files that don't affect the app binary may not need a new build. In these cases, use the skip endpoint to create a neutral check for the pull request's head commit so that it can merge without an unnecessary build. +Your team may require a Size Analysis check on every pull request, even when some CI workflows don't produce a build artifact. For example, a pull request that changes only documentation or other files that don't affect the app binary may not need a new build. In these cases, use the [skip endpoint](/api/mobile-builds/create-a-skipped-size-analysis-status-check/) to create a neutral check for the pull request's head commit so that it can merge without an unnecessary build. The upload and skip paths should be mutually exclusive. Each workflow should @@ -121,11 +121,7 @@ The example below assumes an earlier path-filtering step with an ID of `changes` "https://sentry.io/api/0/projects/$SENTRY_ORG/$SENTRY_PROJECT/preprod/size-analysis/status-checks/skip/" ``` -The request returns an empty `200 OK` response. Set `provider` to `github` for GitHub.com or `github_enterprise` for GitHub Enterprise. - - - This endpoint is experimental and may change. - +This example is configured for GitHub.com. For GitHub Enterprise, set `provider` to `github_enterprise`. ## Configuring Status Check Rules diff --git a/docs/product/snapshots/integrating-into-ci.mdx b/docs/product/snapshots/integrating-into-ci.mdx index 91976d5d06881..db0d2942f6667 100644 --- a/docs/product/snapshots/integrating-into-ci.mdx +++ b/docs/product/snapshots/integrating-into-ci.mdx @@ -63,7 +63,7 @@ For details on the review and approval flow, see [Reviewing Snapshots](/product/ ## Skip the Status Check When No Snapshots Are Uploaded -Your team may require a Snapshot Testing check on every pull request, even when some CI workflows don't produce snapshots. For example, a pull request that changes only documentation or other files that don't affect the rendered UI may not need new snapshots. In these cases, use the skip endpoint to create a neutral check for the pull request's head commit so that it can merge without generating unnecessary snapshots. +Your team may require a Snapshot Testing check on every pull request, even when some CI workflows don't produce snapshots. For example, a pull request that changes only documentation or other files that don't affect the rendered UI may not need new snapshots. In these cases, use the [skip endpoint](/api/snapshots/create-a-skipped-snapshot-status-check/) to create a neutral check for the pull request's head commit so that it can merge without generating unnecessary snapshots. The upload and skip paths should be mutually exclusive. Each workflow should @@ -93,11 +93,7 @@ The example below assumes an earlier path-filtering step with an ID of `changes` "https://sentry.io/api/0/projects/$SENTRY_ORG/$SENTRY_PROJECT/preprod/snapshots/status-checks/skip/" ``` -The request returns an empty `200 OK` response. Set `provider` to `github` for GitHub.com or `github_enterprise` for GitHub Enterprise. - - - This endpoint is experimental and may change. - +This example is configured for GitHub.com. For GitHub Enterprise, set `provider` to `github_enterprise`. ## Troubleshooting