Skip to content

Break out organization identity providers into its own concepts page - #21105

Open
jkodroff wants to merge 2 commits into
masterfrom
jkodroff/identity-providers
Open

Break out organization identity providers into its own concepts page#21105
jkodroff wants to merge 2 commits into
masterfrom
jkodroff/identity-providers

Conversation

@jkodroff

Copy link
Copy Markdown
Member

How a Pulumi organization's membership is backed was documented only at the bottom of the Organizations concepts page, below "Deleting your account," and was never linked from the SAML guides or the version-control integration pages.

Changes

  • Adds /docs/administration/concepts/identity-providers/ covering Pulumi, GitHub, GitLab, Bitbucket, and SAML 2.0 — per-provider setup, the permission required, and the prerequisite that members link the new identity first.
  • Organizations page keeps its ## Organization identity providers heading as a pointer stub, so the existing #organization-identity-providers anchor still resolves (it's linked from billing-managers and two blog posts).
  • Cross-links: info callout + ## Learn more on the GitHub/GitLab/Bitbucket integration pages; reciprocal link from the SAML guides index.
  • Repoints the identity-providers pricing row and the dead per-provider anchors in billing-managers, the Cloud FAQ, and two blog posts.

Corrections verified against pulumi-service

  • The permission is organization:change_backend — admin by default, but an assignable scope, so a custom role can hold it. The RBAC reference described this scope as "backend infrastructure... advanced configuration and migration," which was wrong.
  • Bitbucket alone requires the person making the change to be a workspace admin; GitHub and GitLab have no equivalent check.
  • Only top-level GitLab groups can back an org; subgroups can't.
  • "Disconnecting" a provider means selecting Pulumi — previously unnamed.
  • Added: membership is an AND (Pulumi record + backing membership), the "potential member" concept, one backing org per Pulumi org, SCIM requires a SAML-backed org, and the SAML switch preconditions.

Not asserted: whether GitHub itself requires org-owner approval of the OAuth app. That depends on the GitHub org's third-party access policy and isn't observable from the service source, so the existing hedged wording stands.

Fixes #21093

The only documentation of how a Pulumi organization's membership is backed
lived at the bottom of the Organizations concepts page, below "Deleting your
account," and was never linked from the SAML guides or the version-control
integration pages.

Adds /docs/administration/concepts/identity-providers/ covering Pulumi,
GitHub, GitLab, Bitbucket, and SAML 2.0, with per-provider setup and the
prerequisite that members link the new identity before the switch. The
Organizations page keeps its heading as a pointer stub so the existing
#organization-identity-providers anchor still resolves.

Verified against pulumi-service and corrected several claims: the permission
is organization:change_backend (admin by default, grantable to a custom
role), Bitbucket alone requires workspace admin, only top-level GitLab groups
qualify, and "disconnecting" means selecting Pulumi.

Fixes #21093

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SfR3RL4KvJeyWjdmAiNfZ5
@jkodroff
jkodroff marked this pull request as ready for review August 24, 2026 21:59
@github-actions github-actions Bot added review:triaging Claude Triage is currently classifying the PR domain:docs PR touches technical docs domain:mixed PR touches more than one domain domain:blog PR touches blog posts or customer stories review:in-progress Claude review is currently running and removed review:triaging Claude Triage is currently classifying the PR labels Aug 24, 2026

@unblocked unblocked Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ No issues found

About Unblocked

Unblocked has been set up to automatically review your team's pull requests to identify genuine bugs and issues.

📖 Documentation — Learn more in our docs.

💬 Ask questions — Mention @unblocked to request a review or summary, or ask follow-up questions.

👍 Give feedback — React to comments with 👍 or 👎 to help us improve.

⚙️ Customize — Adjust settings in your preferences.

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Optional style suggestions from the pre-merge review — apply or dismiss; none of them block.


Generated by Claude Code

@github-actions

github-actions Bot commented Aug 24, 2026

Copy link
Copy Markdown
Contributor

Pre-merge Review — Last updated 2026-08-24T23:22:19Z

Tip

Summary: This PR lifts the "Organization identity providers" material out of content/docs/administration/concepts/organizations.md into a new concepts page, identity-providers.md, and repoints every inbound link (concepts index, accounts, billing managers, RBAC scopes, the SAML guide index, the three version-control integration pages, the Pulumi Cloud FAQ, data/pulumi_pricing.yaml, and two blog posts). It parallels the existing per-concept pages in that section (accounts.md, billing-managers.md, access-tokens.md) and renumbers their menu weights to make room at weight 2. The wrongness that would block a reader here is a link that lands nowhere — a repointed link whose target page or anchor doesn't exist, or a stale anchor left behind by the sections deleted from organizations.md. Passes run: link-and-anchor resolution across every changed file, a menu-weight collision sweep of the whole concepts section, external claim verification, a repo-wide grep for references to the five deleted organizations.md sub-anchors, and a cross-sibling read of all 8 concepts siblings. 4a83a2d cleared the blocker and both actionable low-confidence items, and @jkodroff's mention settled the remaining nine with citations. Nothing is outstanding.

Review confidence:

Dimension Level Notes
mechanics HIGH
facts HIGH Raised from MEDIUM. The Pulumi Cloud behavior claims that CI could not source are now confirmed against pulumi/pulumi-service at file:line by the author. That repo is private, so CI cannot independently replay those citations — see 📜 Review history for the evidence class.
coherence HIGH
cross-sibling consistency HIGH
Investigation log
  • Cross-sibling reads: 8 of 8 siblings
  • External claim verification: 60 of 103 claims verified (18 unverifiable, 4 contradicted, 2 framing-drift) · 4 specialists (numerical, cross-reference, capability, framing); 0 cross-specialist corroborations · routed: 0 inline, 81 Pass 1, 8 Pass 2 (verified 0, contradicted 1, unverifiable 7), 14 Pass 3 (verified 8, contradicted 0, unverifiable 6).
  • Cited-claim spot-checks: 8 of 8 cited claims fetched and compared
  • Frontmatter sweep: ran on body + meta_desc
  • Temporal-trigger sweep: ran (recency words present in diff; spot-check in-review)
  • Code execution: not run (no static/programs/ change)
  • Code-examples checks: not run (no fenced code blocks in content files)
  • Editorial-balance pass: ran (single-subject, N/A)
  • Re-entrant pass (4a83a2d): 3 files / 4 lines re-read; new read:org citation fetched (HTTP 200); scripts/redirects/*.txt swept for fragment-bearing source paths (0 of 728 entries); layouts/shortcodes/identities.html and accounts.md:35 read to corroborate the provider-list dispute.
🚨 Outstanding ⚠️ Low-confidence 💡 Pre-existing ✅ Resolved
0 0 4 12

🔍 Verification trail

103 claims extracted · 60 verified · 18 unverifiable · 4 contradicted · 2 framing-drift
  • L68 in content/blog/p3-some-assembly-required/index.md "Pulumi Cloud supports GitLab as an alternative identity provider, documented at https://www.pulumi.com/docs/administration/concepts/identity-providers/#gitlab." → ❌ contradicted (evidence: The cited URL https://www.pulumi.com/docs/administration/concepts/identity-providers/#gitlab returns HTTP 404 (empty body), so the claimed documentation page does not exist at that address.; source: https://www.pulumi.com/docs/administration/concepts/identity-providers/#gitlab)
  • L70 in content/blog/p3-some-assembly-required/index.md "Pulumi Cloud allows use of a variety of identity providers to log in, including GitHub." → ✅ verified (evidence: Pulumi docs confirm Pulumi Cloud supports multiple identity providers for login: "Out of the gate, we supported GitHub as an identity provider when authenticating with the Pulumi service. Since then, we added GitLab, Atlassian, Email…; source: pulumi/docs:content/blog/2019-year-at-a-glance/index.md; pulumi/docs:content/docs/support/faq/pulumi-cloud.md)
  • L70 in content/blog/p3-some-assembly-required/index.md "A Pulumi Cloud organization can help manage teams, roles, stacks, and settings, and provides a dashboard across the entire organization." → ✅ verified (evidence: (escalated from pass1) The blog post states: "A Pulumi Cloud organization can help you manage teams, roles, stacks, settings, and provide a dashboard across the entire organization." This matches the claim's assertion almost verbatim…; source: https://www.pulumi.com/blog/p3-some-assembly-required/)
  • L45 in content/blog/using-pulumi-securely/index.md "Using SSO improves access-control processes across tools and gives organizations more centralized control." → ✅ verified (evidence: Multiple industry sources confirm this general positioning. Okta states: "Centralized control: SSO allows for centralized management of user access and authentication, making it easier to enforce strong security policies" and…; source: https://www.okta.com/blog/identity-security/single-sign-on-sso/; https://www.integrate.io/blog/benefits-single-sign-on-authentication/)
  • L45 in content/blog/using-pulumi-securely/index.md "Leveraging an organization's existing onboarding and offboarding process helps limit the risk of bad actors within Pulumi." → ➖ not-a-claim (evidence: This is a general security-positioning statement about best practices (leveraging existing IAM onboarding/offboarding to reduce insider risk), not a falsifiable factual assertion tied to a specific product feature, statistic, or…; source: content/blog/using-pulumi-securely/index.md)
  • L45 in content/blog/using-pulumi-securely/index.md "SCIM enables organizations to manage users and groups centrally in their Identity Provider (IdP) and synchronize those users and groups to the Pulumi Service." → ✅ verified (evidence: Pulumi's SCIM docs page states: "SCIM enables you to manage your users and groups centrally in your Identity Provider (IdP) and then synchronize those users and groups to the Pulumi Cloud," which matches the claim's assertion almost…; source: repo:content/docs/administration/guides/scim/_index.md)
  • L21 in content/docs/administration/concepts/_index.md "There is a documentation page at /docs/administration/concepts/identity-providers/ describing identity providers that govern organization membership." → ❌ contradicted (evidence: The directory listing of content/docs/administration/concepts on pulumi/docs master shows files for organizations, accounts, agent-accounts, billing-managers, access-tokens, audit-logs, customer-managed-keys, and rbac/ — but no…; source: gh api repos/pulumi/docs/contents/content/docs/administration/concepts)
  • L60 in content/docs/administration/concepts/accounts.md "### Adding new identities {#adding-new-identities}" → ➖ not-a-claim (evidence: This is a markdown section heading ("### Adding new identities") describing a documentation section about associating a Pulumi account with third-party identity providers. It is not a falsifiable temporal assertion.; source: repo:content/docs/administration/concepts/accounts.md)
  • L61-66 in content/docs/administration/concepts/accounts.md "A Pulumi account can be associated with multiple identities, including third-party identity providers in addition to the one originally configured." → ➖ not-a-claim (evidence: The line is a description of Pulumi's own account/identity-linking feature, restated in the same doc's surrounding text: "You can associate your Pulumi account with multiple identities. Besides the one you originally configured, you can…; source: repo:content/docs/administration/concepts/accounts.md)
  • L62 in content/docs/administration/concepts/accounts.md "Besides the identity originally configured, a Pulumi user can add identities from the third-party providers listed in the identities section." → ✅ verified (evidence: The same doc states: "You can associate your Pulumi account with multiple identities. Besides the one you originally configured, you can add identities from the following third-party providers:" followed by the {{< identities >}}…; source: repo:content/docs/administration/concepts/accounts.md)
  • L68-70 in content/docs/administration/concepts/accounts.md "To connect an additional identity, click your account avatar in the top right corner, select Account settings, then in the Identity providers section find…" → ➖ not-a-claim (evidence: This is a verbatim restatement of the doc's own step-by-step instructions (lines 68-70: '1. Click on your account avatar... 2. Select Account settings... 3. In the Identity providers section, find the provider under Available identities…; source: repo:content/docs/administration/concepts/accounts.md)
  • L72 in content/docs/administration/concepts/accounts.md "Only organization admins can add members to a Pulumi organization." → ✅ verified (evidence: The sibling doc content/docs/administration/concepts/organizations.md states: "Pulumi organization administrators can invite new members to an organization" and the roles table describes Admin as having "full access to the organization…; source: repo:content/docs/administration/concepts/organizations.md)
  • L72 in content/docs/administration/concepts/accounts.md "Connecting additional identities lets a user join Pulumi organizations that are backed by those identity systems." → ✅ verified (evidence: The source file states verbatim: "Connecting these additional identities lets you join Pulumi organizations that are backed by those systems." This matches the claim's assertion exactly (minor paraphrase: "these"/"you" vs "additional"/"a…; source: repo:content/docs/administration/concepts/accounts.md (line 72))
  • L74 in content/docs/administration/concepts/accounts.md "Once a user's account is linked to their third-party identity, the user shows up on the list of users that the organization admin can invite." → ✅ verified (evidence: The linked page states: "A user who belongs to the backing system but has not been added to the Pulumi organization yet is a potential member. Potential members appear on the list of people an organization admin can invite, but they…; source: content/docs/administration/concepts/identity-providers.md)
  • L10 in content/docs/administration/concepts/billing-managers.md "In the frontmatter navigation weighting for the administration concepts section, the Billing managers page has a weight of 5." → ✅ verified (evidence: (escalated from pass3) File frontmatter reads: menu: administration: name: Billing managers, parent: administration-concepts, weight: 5 — matching the claim exactly.; source: repo:content/docs/administration/concepts/billing-managers.md)
  • L30 in content/docs/administration/concepts/billing-managers.md "Billing Managers, like members, must be members of the organization identity provider in order to gain access to the Pulumi organization." → ✅ verified (evidence: The linked identity-providers.md page states: "Every Pulumi organization is backed by exactly one identity provider, which governs who is allowed to be a member... a user must belong to the Pulumi organization and be a current member…; source: repo:content/docs/administration/concepts/identity-providers.md)
  • L9 in content/docs/administration/concepts/customer-managed-keys.md "This Customer Managed Keys documentation page has a menu weight of 9 within the administration-concepts section." → ➖ not-a-claim (evidence: The file's front matter directly shows menu: administration: parent: administration-concepts, weight: 9, matching the claim exactly — this is a restatement of the page's own metadata, not a falsifiable third-party assertion.; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
  • L20-22 in content/docs/administration/concepts/customer-managed-keys.md "Pulumi Cloud supports Customer Managed Keys (CMKs), which allow users to use their own encryption keys from an external Key Management System (KMS) to…" → 🌀 framing-drift (framing: overclaim — claim states CMKs protect "sensitive data in Pulumi Cloud" generally, but the doc itself notes CMKs currently only encrypt data in Pulumi ESC (a…; evidence: The doc's overview states CMKs "allow you to use your own encryption keys to protect sensitive data in Pulumi Cloud through an external Key Management System (KMS)" but the same page's info note qualifies this: "Currently, Customer…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
  • L24-26 in content/docs/administration/concepts/customer-managed-keys.md "CMKs encrypt data keys, which are in turn used to encrypt data in Pulumi Cloud." → ✅ verified (framing: Claim states the encrypt-data-keys mechanism generally for "Pulumi Cloud"; the doc's own info box and the ESC sibling page confirm the mechanism, currently…; evidence: The sibling ESC-specific docs page (content/docs/esc/concepts/customer-managed-keys.md) states the identical mechanism: "CMKs encrypt data keys, which are used to encrypt secrets in Pulumi ESC." This confirms the two-tier…; source: repo:content/docs/esc/concepts/customer-managed-keys.md)
  • L24-26 in content/docs/administration/concepts/customer-managed-keys.md "When a customer adds their first CMK, all existing data keys encrypted with the Pulumi-managed key are automatically re-encrypted with the new CMK." → ✅ verified (evidence: The claim is consistent throughout the same doc: "When you add your first CMK, all existing data keys encrypted with the Pulumi-managed key will be automatically re-encrypted with the new CMK" and again in the info box "When the first…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
  • L28 in content/docs/administration/concepts/customer-managed-keys.md "Only organization admins can manage Customer Managed Keys in Pulumi Cloud." → ✅ verified (evidence: The doc states "Only organization admins can manage CMKs" and the viewing/management instructions consistently require admin access ("As an admin, expand the organization's Settings menu"), confirming the access-control claim is…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
  • L30-34 in content/docs/administration/concepts/customer-managed-keys.md "Pulumi is working on adding support for more KMS providers and expanding Customer Managed Key encryption to additional Pulumi products beyond ESC." → ➖ not-a-claim (evidence: The claim is a direct restatement of the doc's own info-box text: "We are working on adding support for more KMS providers and expanding encryption to additional Pulumi products." This is a forward-looking statement about Pulumi's own…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
  • L41-43 in content/docs/administration/concepts/customer-managed-keys.md "To view Customer Managed Keys as an admin, you expand the organization's Settings menu, select Organization, then select the Customer Managed Keys tab." → ✅ verified (evidence: The same document states: "To view Customer Managed Keys: 1. As an admin, expand the organization's Settings menu. 1. Select Organization. 1. Select the Customer Managed Keys tab." This matches the claim's described navigation steps…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
  • L45-54 in content/docs/administration/concepts/customer-managed-keys.md "The Customer Managed Keys page displays a Default field indicating if the key is the default encryption key for the organization, and all new data keys are…" → ✅ verified (evidence: The doc itself states: "Default: Indicates if the key is the default encryption key for the organization. All new data keys responsible for encrypting data created by your organization will be encrypted with this key." This matches…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
  • L49-50 in content/docs/administration/concepts/customer-managed-keys.md "All new data keys responsible for encrypting data created by an organization will be encrypted with the default key." → 🤷 unverifiable (evidence: This describes internal Pulumi Cloud SaaS UI/product behavior (Customer Managed Keys feature) that isn't exposed in open-source pulumi/pulumi repos to check against. The claim is internally consistent with the rest of the same doc…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
  • L58 in content/docs/administration/concepts/customer-managed-keys.md "Adding a Customer Managed Key enables users to use their own encryption key to protect sensitive data in Pulumi Cloud." → 🌀 framing-drift (framing: overclaim — claim says "protect sensitive data in Pulumi Cloud" broadly, but source qualifies "Currently...only used to encrypt data in Pulumi ESC"; evidence: The same page states "Currently, Customer Managed Keys are only used to encrypt data in Pulumi ESC, and only AWS KMS is supported," so the claim's broad phrasing "protect sensitive data in Pulumi Cloud" overstates current scope, which is…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
  • L60-62 in content/docs/administration/concepts/customer-managed-keys.md "When the first Customer Managed Key is added, all data keys encrypted with the Pulumi-managed key are automatically re-encrypted with the new Customer…" → ✅ verified (evidence: Independently corroborated by the Pulumi blog announcing the CMK feature: "Customer-Managed Keys integrate seamlessly with your Pulumi Cloud Organization. Once enabled, all existing data keys used to encrypt your ESC secrets, previously…; source: content/blog/bring-your-own-keys-with-pulumi-esc/index.md; content/docs/administration/concepts/customer-managed-keys.md)
  • L67-73 in content/docs/administration/concepts/customer-managed-keys.md "Adding an AWS KMS Customer Managed Key in Pulumi Cloud requires navigating to the Customer Managed Keys settings page, clicking Add Customer Managed Key…" → ➖ not-a-claim (evidence: The claim is a verbatim restatement of the doc's own numbered procedure: "Go to the Customer Managed Keys settings page... Click Add Customer Managed Key... Enter a unique name... Provide the Role ARN with access to the AWS KMS key...…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
  • L77-78 in content/docs/administration/concepts/customer-managed-keys.md "Disabling a Customer Managed Key prevents it from being used to create new data keys, but existing data keys remain encrypted with that key until they are…" → ➖ not-a-claim (evidence: The claim text is a near-verbatim restatement of the doc's own content at lines 77-78: "Disabling a key prevents it from being used to create new data keys, but existing data keys remain encrypted with the key until they are…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
  • L80 in content/docs/administration/concepts/customer-managed-keys.md "Disabling a Customer Managed Key is not available for default keys or keys undergoing re-encryption." → ✅ verified (evidence: The doc states this exact behavior twice: "Disable: A button to disable the key. This option is unavailable for default keys or keys undergoing re-encryption." (L53-54) and "Disabling a key is not available for default keys or keys…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
  • L84-88 in content/docs/administration/concepts/customer-managed-keys.md "To disable a Customer Managed Key, you click the three-dot menu next to the key, select Disable, choose a re-encryption key, click Disable to confirm, and a…" (also L100) → ➖ not-a-claim (evidence: Lines 84-88 in the file exactly match the claim text step-by-step ("Click the three-dot menu... Select Disable... Choose a re-encryption key... Click Disable to confirm... A banner will appear, showing the re-encryption process status.…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
  • L88 in content/docs/administration/concepts/customer-managed-keys.md "After confirming disabling a Customer Managed Key, a banner appears showing the re-encryption process status and disappears once the process is complete." → 🤷 unverifiable (evidence: The claim restates the doc's own UI walkthrough step ("A banner will appear, showing the re-encryption process status. It disappears once the process is complete."). This describes Pulumi Cloud SaaS UI behavior whose frontend source is…; source: repo:content/docs/administration/concepts/customer-managed-keys.md#L88)
  • L92-93 in content/docs/administration/concepts/customer-managed-keys.md "Disabling all Customer Managed Keys prevents them from being used to create new data keys, but existing data keys remain encrypted with the keys until they…" → ➖ not-a-claim (evidence: The claim is a verbatim restatement of the doc's own text: "Disabling all keys prevents them from being used to create new data keys, but existing data keys remain encrypted with the keys until they are re-encrypted. All data keys will…; source: repo:content/docs/administration/concepts/customer-managed-keys.md (L92-93))
  • L93 in content/docs/administration/concepts/customer-managed-keys.md "When all Customer Managed Keys are disabled, all data keys will be re-encrypted with the Pulumi-managed key." → ✅ verified (evidence: The doc's own "Disabling All Customer Managed Keys" section states: "Disabling all keys prevents them from being used to create new data keys, but existing data keys remain encrypted with the keys until they are re-encrypted. All data…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
  • L97-100 in content/docs/administration/concepts/customer-managed-keys.md "To disable all Customer Managed Keys, a user clicks the wheel button in the top right corner, clicks 'Disable all Customer Managed Keys', confirms the…" → ➖ not-a-claim (evidence: The claim is a verbatim paraphrase of the doc's own numbered steps (L97-100): '1. Click on the wheel button in the top right corner. 2. Click Disable all Customer Managed Keys. 3. Confirm the re-encryption process in the dialog that…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
  • L100 in content/docs/administration/concepts/customer-managed-keys.md "After confirming disabling all Customer Managed Keys, a banner appears showing the re-encryption process status and disappears once the process is complete." → ➖ not-a-claim (evidence: Line 100-101 states "Click Disable all to confirm. A banner will appear, showing the re-encryption process status. It disappears once the process is complete." This is the doc's own description of Pulumi Cloud UI behavior with no…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
  • L3 in content/docs/administration/concepts/identity-providers.md "Pulumi Cloud organizations can be backed by GitHub, GitLab, Bitbucket, or a SAML 2.0 identity provider." → 🤷 unverifiable (evidence: The doc's own "Available identity providers" table lists Pulumi, GitHub, GitLab, Bitbucket, and SAML 2.0 — consistent with the claim. However, the underlying pulumi-pulumiservice API type IdentityProvider…; source: gh api repos/pulumi/pulumi-pulumiservice/contents/provider/pkg/apitype/identity_provider_.go; intuition: Product enum includes AzureDevOps and Google identity provider constants not mentioned in the claim's list — possibly…)
  • L14 in content/docs/administration/concepts/identity-providers.md "A Pulumi organization can be backed by a GitHub organization, a GitLab group, a Bitbucket workspace, or a SAML 2.0 identity provider." → ✅ verified (evidence: The pulumi-pulumiservice provider source defines an IdentityProvider/OrganizationKind enum with exactly these backing types (identity_provider_.go / organization_kind_.go: cases for GitHub, GitLab, Bitbucket) plus SAML auth support…; source: gh search code --owner pulumi identity_provider_.go / organization_kind_.go in pulumi/pulumi-pulumiservice)
  • L16 in content/docs/administration/concepts/identity-providers.md "When a Pulumi organization is backed by a third party, membership requires a user to both belong to the Pulumi organization and be a current member of the…" → ➖ not-a-claim (evidence: Line 16 of the file itself reads: "When an organization is backed by a third party, membership is the intersection of two things: a user must belong to the Pulumi organization and be a current member of the backing organization, group…; source: repo:content/docs/administration/concepts/identity-providers.md)
  • L16 in content/docs/administration/concepts/identity-providers.md "As soon as someone loses access to the backing system (GitHub organization, GitLab group, Bitbucket workspace, or SAML identity provider), they lose access…" → ✅ verified (evidence: The doc itself states the mechanism directly: "membership is the intersection of two things: a user must belong to the Pulumi organization and be a current member of the backing organization, group, or workspace. As soon as someone loses…; source: content/docs/administration/concepts/identity-providers.md)
  • L18 in content/docs/administration/concepts/identity-providers.md "A user who belongs to the backing system but has not been added to the Pulumi organization yet is classified as a 'potential member'." → ✅ verified (evidence: The pulumi-pulumiservice provider source defines this concept directly: "PotentialOrganizations is the list of Pulumi organizations the user is a potential member of," matching the doc's definition that a user in the backing system but…; source: gh search code --owner pulumi "potential member" (pulumi/pulumi-pulumiservice:provider/pkg/apitype/user_.go))
  • L18 in content/docs/administration/concepts/identity-providers.md "Potential members appear on the list of people an organization admin can invite, but cannot use the organization until they are added." → ✅ verified (evidence: Pulumi's own service API models this exact concept: pulumi-pulumiservice's User type has a field "PotentialOrganizations is the list of Pulumi organizations the user is a potential member of," confirming "potential member" is a real…; source: gh api repos/pulumi/pulumi-pulumiservice/contents/provider/pkg/apitype/user_.go (PotentialOrganizations field))
  • L22-28 in content/docs/administration/concepts/identity-providers.md "With SAML 2.0 as the identity provider, membership comes from the users the identity provider assigns to the Pulumi application." → ➖ not-a-claim (evidence: The claim paraphrases the doc's own table row (L28: "SAML 2.0 | The users your identity provider assigns to the Pulumi application") which is itself restated verbatim later in the same file's SAML section: "A SAML-backed organization…; source: repo:content/docs/administration/concepts/identity-providers.md)
  • L24 in content/docs/administration/concepts/identity-providers.md "The Pulumi identity provider is the default for new organizations and requires no third-party configuration." → 🤷 unverifiable (evidence: The claim describes Pulumi Cloud's own SaaS default behavior. The reviewed page itself states "New organizations use the Pulumi identity provider, where membership is managed entirely in Pulumi Cloud" and the table row: "The default for…; source: repo:content/docs/administration/concepts/organizations.md and repo:content/docs/administration/concepts/identity-providers.md)
  • L30 in content/docs/administration/concepts/identity-providers.md "An organization can use only one identity provider at a time, and selecting a new identity provider replaces the old one." → ✅ verified (evidence: The doc states "Every Pulumi organization is backed by exactly one identity provider" and "These options are mutually exclusive. An organization uses one identity provider at a time, and selecting a new one replaces the old one." This…; source: repo:content/docs/administration/concepts/identity-providers.md; pulumi/pulumi-pulumiservice:provider/pkg/apitype/rbac_permission_.go)
  • L34 in content/docs/administration/concepts/identity-providers.md "Pulumi does not check in advance whether an organization's existing members can meet the new identity provider requirement." → ➖ not-a-claim (evidence: The claim text is a near-verbatim restatement of the doc's own line 34: "Pulumi does not check in advance whether your existing members can meet the new requirement." This is the doc author describing Pulumi's own product behavior in its…; source: repo:content/docs/administration/concepts/identity-providers.md)
  • L38-39 in content/docs/administration/concepts/identity-providers.md "You cannot select an identity provider you have no identity linked for, and if you lock yourself out of an organization by changing the identity provider…" → 🤷 unverifiable (evidence: The claim paraphrases the doc's own text ("You cannot select a provider you have no identity for, and if you lock yourself out you cannot change the setting back"), which is internally consistent with the rest of the page (e.g., "Anyone…; source: repo:content/docs/administration/concepts/identity-providers.md)
  • L39 in content/docs/administration/concepts/identity-providers.md "The steps for adding new identities are documented at /docs/administration/concepts/accounts/#adding-new-identities." → ✅ verified (evidence: accounts.md contains a heading "### Adding new identities {#adding-new-identities}" which matches the anchor referenced in the claim's URL /docs/administration/concepts/accounts/#adding-new-identities.; source: repo:content/docs/administration/concepts/accounts.md)
  • L42 in content/docs/administration/concepts/identity-providers.md "Members who do not meet a new identity provider requirement regain access as soon as they link the required identity and belong to the backing organization." → ✅ verified (framing: Source states the general rule (membership requires backing org membership + linked identity, and loss of either revokes access); claim states the narrower…; evidence: (escalated from pass1) Pulumi's organizations documentation describes the same access-linkage mechanism: "Organization members must first add the new identity provider to their individual accounts before changing the organization…; source: https://www.pulumi.com/docs/administration/organizations-teams/organizations/)
  • L46 in content/docs/administration/concepts/identity-providers.md "The full list of organization-level RBAC permissions is documented at /docs/administration/reference/rbac-scopes/org-settings/." → ✅ verified (evidence: The page at content/docs/administration/reference/rbac-scopes/org-settings.md is titled "RBAC Scopes: Organization Settings" and lists organization-level scopes including organization:change_backend — "Change the organization's…; source: repo:content/docs/administration/reference/rbac-scopes/org-settings.md)
  • L48 in content/docs/administration/concepts/identity-providers.md "To select a Bitbucket workspace as the identity provider, you must also be an admin of that workspace." → ✅ verified (framing: Source describes the admin requirement in the context of connecting/adding the Bitbucket-backed org; claim states it as a requirement to "select" the…; evidence: (escalated from pass1) Pulumi's own organizations docs state that to add a Bitbucket-backed organization, "an admin of the Atlassian Bitbucket workspace must first grant the Pulumi Oauth app read access to their Bitbucket account and…; source: https://pulumi.com/docs/pulumi-cloud/admin/organizations)
  • L52-56 in content/docs/administration/concepts/identity-providers.md "To change an organization's identity provider in Pulumi Cloud, navigate to Settings > Access management, select the Other tab, select Change requirements in…" → ➖ not-a-claim (evidence: The claim text is a verbatim paraphrase of the document's own numbered steps at L52-56 ("Navigate to Settings > Access management. Select the Other tab. In the Membership Requirements section, select Change requirements. On the Select…; source: repo:content/docs/administration/concepts/identity-providers.md)
  • L58 in content/docs/administration/concepts/identity-providers.md "A change to the organization's identity provider takes effect immediately and is recorded in the organization's audit logs." → ✅ verified (framing: Source lists a general "Organization Settings Changed" audit event; claim specifies the narrower case of identity-provider/membership-requirement changes…; evidence: The audit-logs page lists "Organization Settings Changed — indicates a change in organization settings" as a tracked audit event, and describes audit logs as recording all user actions with timestamps immediately as they occur; this…; source: repo:content/docs/administration/concepts/audit-logs.md)
  • L61 in content/docs/administration/concepts/identity-providers.md "If a GitHub organization, GitLab group, or Bitbucket workspace already backs another Pulumi organization, Pulumi rejects the change with the message 'That…" → 🤷 unverifiable (evidence: (escalated from pass1) Web search did not surface any Pulumi documentation, changelog, or support content describing the specific error message 'That organization is already registered' for duplicate GitHub/GitLab/Bitbucket identity…; source: WebSearch ran query "Pulumi "that organization is already registered" error"; top results didn't address the claim)
  • L64 in content/docs/administration/concepts/identity-providers.md "The Membership Requirements section does not appear for individual accounts or for legacy per-stack organizations." → 🤷 unverifiable (evidence: (escalated from pass1) Search results describe the Membership Requirements section generally (found under Settings > Access Management > Other tab) but do not address its visibility conditions for individual accounts or legacy per-stack…; source: WebSearch ran query "Pulumi identity providers "Membership Requirements" per-stack organizations"; top results didn't address the claim)
  • L68 in content/docs/administration/concepts/identity-providers.md "Only members of the backing GitHub organization can belong to a GitHub-backed Pulumi organization." → 🤷 unverifiable (evidence: The cited GitHub Docs page is about creating a new GitHub organization from scratch; the fetched body (truncated) shows only navigation/breadcrumb content with no mention of Pulumi organizations or GitHub-backed org membership rules.…; source: https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch; intuition: Claim describes Pulumi's own product behavior (GitHub-backed org membership restriction) but cites a generic GitHub…)
  • L73 in content/docs/administration/concepts/identity-providers.md "Pulumi does not get access to source code, issues, or any other GitHub organization data when connected via the read:org scope." → ✅ verified (evidence: The doc states the OAuth app requests only the read:org scope "which Pulumi uses to verify who belongs to the organization" and that "Pulumi does not get access to source code, issues, or any other organization data." This is…; source: content/docs/administration/concepts/identity-providers.md L73; GitHub OAuth scopes reference (read:org scope description))
  • L73 in content/docs/administration/concepts/identity-providers.md "Depending on the GitHub organization's third-party application policy, a GitHub organization owner may need to grant or approve authorization for the Pulumi…" → 🤷 unverifiable (framing: Cited URL is a private, user-specific settings page requiring authentication, not a public documentation source that could confirm or deny the claim's…; evidence: The cited URL is a personal GitHub account settings page (requires sign-in) that returns a login prompt rather than any content about OAuth app authorization policy: "Sign in to GitHub · GitHub Skip to content You signed in with another…; source: https://github.com/settings/connections/applications/7cf9078f3c92b17a5f0f)
  • L76 in content/docs/administration/concepts/identity-providers.md "Until a member authorizes their GitHub credential for an organization enforcing SAML SSO, GitHub does not report their membership to Pulumi and they cannot…" → ✅ verified (evidence: This describes GitHub's well-documented SAML SSO enforcement behavior: when a GitHub org enforces SAML SSO, OAuth apps/tokens (including the read:org scope Pulumi's integration relies on, per the same doc's step 2) cannot see a…; source: repo:content/docs/administration/concepts/identity-providers.md L73-76; gh search code --owner pulumi apitype/pulumi_git_hub_organization_.go)
  • L80 in content/docs/administration/concepts/identity-providers.md "Subgroups cannot back a Pulumi organization; only a top-level GitLab group can." → 🤷 unverifiable (evidence: The fetched GitLab Groups documentation page explains the general concept of top-level groups and subgroups (group hierarchy), but nowhere mentions Pulumi, Pulumi organizations, or any restriction that only top-level GitLab groups (and…; source: https://docs.gitlab.com/user/group/; intuition: Claim describes a Pulumi-side integration constraint (which GitLab group types can back a Pulumi org) but cites a…)
  • L88 in content/docs/administration/concepts/identity-providers.md "A member whose GitLab group membership has expired, or is in any state other than active, loses access to the Pulumi organization." → ✅ verified (framing: Source explicitly covers "expires"; claim's added phrase "or is in any state other than active" generalizes slightly but is consistent with the same…; evidence: (escalated from pass1) Pulumi's official docs state: "As soon as their GitLab group membership expires, those users will lose access to Pulumi organization." This directly supports the claim's core assertion about expired GitLab group…; source: https://www.pulumi.com/docs/administration/organizations-teams/organizations/)
  • L88 in content/docs/administration/concepts/identity-providers.md "GitLab lets group owners grant memberships that expire." → ✅ verified (evidence: GitLab's own source (gitlabhq/gitlabhq) confirms group memberships support an expires_at field, exposed via the Group Members API (example response includes "expires_at": "2012-10-22") and exercised by a spec file…; source: gh api repos/gitlabhq/gitlabhq/contents/doc/api/group_members.md; gh search code --repo gitlabhq/gitlabhq "expires_at group member")
  • L92 in content/docs/administration/concepts/identity-providers.md "Bitbucket identities are labeled 'Atlassian' in Pulumi account settings." → 🤷 unverifiable (evidence: The cited Atlassian support page is about 'What is a workspace?' in Bitbucket Cloud and contains no information about how Pulumi labels Bitbucket identities in its account settings UI. This is a Pulumi product-UI claim that the cited…; source: https://support.atlassian.com/bitbucket-cloud/docs/what-is-a-workspace/; intuition: Claim describes Pulumi's own UI labeling behavior but cites an unrelated third-party Atlassian page as source …)
  • L95 in content/docs/administration/concepts/identity-providers.md "Bitbucket's member-listing API behaves differently for admins than for other members, so Pulumi verifies workspace admin status up front rather than failing…" → 🤷 unverifiable (evidence: (escalated from pass3) The claim describes an internal rationale for Pulumi Cloud's Bitbucket integration design (a closed-source SaaS backend) — specifically that Bitbucket's member-listing API behaves differently for admins vs. other…; source: gh search code --owner pulumi "bitbucket workspace admin" / "bitbucket member-listing" (no results))
  • L95 in content/docs/administration/concepts/identity-providers.md "Pulumi verifies Bitbucket workspace admin status up front rather than failing later." → 🤷 unverifiable (evidence: (escalated from pass1) This claim describes Pulumi's own product/CLI behavior (validation order for Bitbucket workspace admin status during identity provider setup), which requires checking Pulumi's own source or internal behavior rather…; source: N/A - product behavior claim not resolvable via web search (WebSearch dispatched but verification did not converge within the turn budget))
  • L95 in content/docs/administration/concepts/identity-providers.md "Unlike GitHub and GitLab, Bitbucket requires that whoever makes the identity-provider change be an admin of the target Bitbucket workspace." → ✅ verified (framing: Source describes admin requirements for each provider separately; claim's contrast framing ("unlike GitHub and GitLab") is a reasonable synthesis of the…; evidence: Pulumi's own docs state that for GitHub "an admin of the GitHub organization must first grant the Pulumi OAuth app the read:org scope," for GitLab "an admin of the GitLab group must add the group to Pulumi," and for Bitbucket "an admin…; source: https://pulumi.com/docs/pulumi-cloud/admin/organizations)
  • L100 in content/docs/administration/concepts/identity-providers.md "Connecting an Atlassian identity to a Pulumi account grants the Pulumi OAuth app read access to the user's Bitbucket account and workspace membership…" → 🤷 unverifiable (evidence: The pre-fetched page content is mostly boilerplate JS/config from the Confluence page shell and the visible body text covers OAuth consumer creation steps, not the specific scopes granted to a connected Atlassian/Bitbucket OAuth app…; source: https://confluence.atlassian.com/bitbucket/oauth-on-bitbucket-cloud-238027431.html#OAuthonBitbucketCloud-Scopes)
  • L104 in content/docs/administration/concepts/identity-providers.md "Once a Pulumi organization is switched to Bitbucket-backed identity, admins can see the list of Bitbucket workspace members and add or invite them to the…" → ➖ not-a-claim (evidence: The claim is a direct paraphrase of the document's own line 104 ("Once the change is complete, admins can see the list of Bitbucket workspace members and add or invite them to the Pulumi organization"), which is consistent with the doc's…; source: repo:content/docs/administration/concepts/identity-providers.md#L104)
  • L110 in content/docs/administration/concepts/identity-providers.md "Pulumi Cloud works with any SAML 2.0 identity provider, including Microsoft Entra ID, Google Workspace, Okta, OneLogin, Auth0, and JumpCloud." → ✅ verified (evidence: The SAML SSO guides index states "The Pulumi Cloud can be configured to work with any SAML 2.0 identity provider" and lists Integration Guides for exactly: Microsoft Entra ID, Google Workspace, JumpCloud, Okta, Auth0, and OneLogin …; source: repo:content/docs/administration/guides/saml/_index.md)
  • L112 in content/docs/administration/concepts/identity-providers.md "Configuring SAML is covered by the SAML SSO guides. Two things are specific to switching your organization to SAML:" → ✅ verified (evidence: The linked page at content/docs/administration/guides/saml/_index.md exists and is titled "SAML(SSO)" / "SAML Single Sign-On (SSO) Guides", providing an overview of configuring SAML 2.0 identity providers with Pulumi Cloud plus…; source: repo:content/docs/administration/guides/saml/_index.md)
  • L114-115 in content/docs/administration/concepts/identity-providers.md "When configuring SAML for an organization, Pulumi makes the user who applies the SAML configuration the organization owner, so that an error in the identity…" → 🤷 unverifiable (evidence: (escalated from pass1) Pulumi's SAML troubleshooting docs confirm the general lockout-prevention concept: "If you are locked out of your Pulumi organization due to a SAML configuration error or an expired certificate, a SAML admin can…; source: https://www.pulumi.com/docs/administration/access-identity/saml/troubleshooting/; intuition: Claim describes a specific internal product behavior (auto-assigning ownership on SAML config) that public docs… (WebSearch dispatched but verification did not converge within the turn budget))
  • L114 in content/docs/administration/concepts/identity-providers.md "Making the SAML configuration applier the organization owner is designed so that an error in the identity provider metadata cannot lock everyone out of the…" → ➖ not-a-claim (evidence: The claim is a verbatim paraphrase of the doc's own text: "Pulumi makes the user who applies the SAML configuration the organization owner, so that an error in the identity provider metadata cannot lock everyone out of the organization."…; source: repo:content/docs/administration/concepts/identity-providers.md:114)
  • L115 in content/docs/administration/concepts/identity-providers.md "To switch an organization to SAML, your individual account must not own any stacks or environments." → 🤷 unverifiable (evidence: (escalated from pass1) Related Pulumi docs confirm that changing an organization's identity provider requires members to add the new provider to their account first or risk lockout, and that deleting an account requires transferring…; source: WebSearch ran query "Pulumi identity-providers.md individual account own stacks environments SAML organization"; top results didn't state this exact requirement)
  • L117 in content/docs/administration/concepts/identity-providers.md "Switching a SAML-backed organization to another identity provider stops SCIM provisioning." → ✅ verified (framing: The claim is a direct restatement (not a wider generalization) of the doc's own adjacent sentence about SCIM being SAML-exclusive plus the mutual-exclusivity…; evidence: The same page states "SCIM provisioning is available only for SAML-backed organizations, and the SAML & SCIM settings tab appears only once your organization is SAML-backed" and earlier that identity providers "are mutually exclusive...…; source: repo:content/docs/administration/concepts/identity-providers.md and repo:content/docs/administration/guides/scim/_index.md)
  • L119 in content/docs/administration/concepts/identity-providers.md "Members of a SAML-backed organization can sign in with the organization name pre-filled by visiting https://app.pulumi.com/welcome//sso." → 🤷 unverifiable (evidence: The pre-fetched URL https://app.pulumi.com/welcome/ returned only a bare "Pulumi Cloud" shell (likely a JS SPA), which does not contain any content confirming the SSO sign-in flow with a pre-filled organization name at the…; source: https://app.pulumi.com/welcome/)
  • L123 in content/docs/administration/concepts/identity-providers.md "You remove a third-party identity provider from a Pulumi organization by selecting a different one; there is no 'none' option." → ✅ verified (evidence: (escalated from pass1) Pulumi's own docs state: "In order to disconnect an identity provider you need to select another identity provider," and this applies to third-party/SAML SSO providers, with no 'none' option offered.; source: https://www.pulumi.com/docs/administration/organizations-teams/organizations/)
  • L125 in content/docs/administration/concepts/identity-providers.md "Selecting Pulumi as the identity provider is also how you remove a SAML SSO configuration from an organization." → ➖ not-a-claim (evidence: The line is a direct restatement of the doc's own preceding sentence: "You remove a third-party identity provider by selecting a different one — there is no 'none' option. ... select Pulumi. This is also how you remove a SAML SSO…; source: repo:content/docs/administration/concepts/identity-providers.md)
  • L129 in content/docs/administration/concepts/identity-providers.md "- Accounts — linking third-party identities to your individual Pulumi account." → ✅ verified (evidence: The target page content/docs/administration/concepts/accounts.md (which serves at /docs/administration/concepts/accounts/) contains a section "Adding New Identities" stating: "You can associate your Pulumi account with multiple…; source: gh api repos/pulumi/docs/contents/content/docs/administration/concepts/accounts.md)
  • L130 in content/docs/administration/concepts/identity-providers.md "- Organizations — creating organizations, inviting members, and organization roles." → ✅ verified (evidence: content/docs/administration/concepts/organizations.md exists and renders at /docs/administration/concepts/organizations/, with sections "## Creating an organization", "## Inviting members to an organization", and "## Organization roles"…; source: repo:content/docs/administration/concepts/organizations.md)
  • L131-132 in content/docs/administration/concepts/identity-providers.md "- SCIM — automating user and team provisioning from your identity provider." → ✅ verified (evidence: The target page content/docs/administration/guides/scim/_index.md exists and describes SCIM as provisioning users (org members) and groups (teams) from the identity provider: "SCIM enables you to manage your users and groups centrally in…; source: repo:content/docs/administration/guides/scim/_index.md)
  • L133 in content/docs/administration/concepts/identity-providers.md "- Organization settings scopes — the full list of organization-level RBAC permissions." → ✅ verified (evidence: The page content/docs/administration/reference/rbac-scopes/org-settings.md exists, resolves to URL /docs/administration/reference/rbac-scopes/org-settings/, with title "RBAC Scopes: Organization Settings" and lists full RBAC scope…; source: gh api repos/pulumi/docs/contents/content/docs/administration/reference/rbac-scopes/org-settings.md)
  • L54 in content/docs/administration/concepts/organizations.md "The Identity providers page (/docs/administration/concepts/identity-providers/) contains the full list of identity provider options available for Pulumi…" (also L175) → ✅ verified (evidence: content/docs/administration/concepts/identity-providers.md exists at that path and contains an "Available identity providers" table listing Pulumi, GitHub, GitLab, Bitbucket, and SAML 2.0 as the full set of options, matching the claim's…; source: repo:content/docs/administration/concepts/identity-providers.md)
  • L173 in content/docs/administration/concepts/organizations.md "Every Pulumi organization is backed by an identity provider that governs who can be a member of the organization." → ✅ verified (evidence: Sibling page content/docs/administration/concepts/identity-providers.md states: "Every Pulumi organization is backed by exactly one identity provider, which governs who is allowed to be a member... You can instead back an organization…; source: repo:content/docs/administration/concepts/identity-providers.md)
  • L175 in content/docs/administration/concepts/organizations.md "The Identity providers page at /docs/administration/concepts/identity-providers/ exists and contains the full list of identity provider options." → ✅ verified (evidence: The file content/docs/administration/concepts/identity-providers.md exists at that path and contains an "## Available identity providers" section with a table listing Pulumi, GitHub, GitLab, Bitbucket, and SAML 2.0 as identity provider…; source: repo:content/docs/administration/concepts/identity-providers.md)
  • L22 in content/docs/administration/guides/saml/_index.md "The identity-providers concept page at /docs/administration/concepts/identity-providers/ documents identity providers that can back a Pulumi organization's…" → 🤷 unverifiable (evidence: The claim's actual assertion is about the cross-reference target /docs/administration/concepts/identity-providers/ existing, but the pre-fetched URL is https://app.pulumi.com/signin (a sign-in page returning only 'Pulumi Cloud'), which…; source: https://app.pulumi.com/signin; intuition: Source hint URL (app.pulumi.com/signin) does not match the claim's actual cited path (/docs/administration/concepts/ide…)
  • L132 in content/docs/administration/reference/rbac-scopes/org-settings.md "The organization:change_backend RBAC scope changes the organization's identity provider — the GitHub organization, GitLab group, Bitbucket workspace, or…" → ✅ verified (evidence: The identity-providers doc states "Every Pulumi organization is backed by exactly one identity provider, which governs who is allowed to be a member... You can instead back an organization with a GitHub organization, a GitLab group, a…; source: repo:content/docs/administration/concepts/identity-providers.md)
  • L16 in content/docs/integrations/version-control/bitbucket.md "Once configured, Pulumi automatically registers a webhook on each Bitbucket repository wired up for deployments." → ✅ verified (evidence: The same page explicitly elaborates on this exact mechanism later in the doc: "Pulumi automatically registers a webhook on each Bitbucket repository the first time you save deployment settings on a stack that targets that repository. No…; source: repo:content/docs/integrations/version-control/bitbucket.md)
  • L16 in content/docs/integrations/version-control/bitbucket.md "GitHub, via the Pulumi GitHub App, provides the same capabilities as the Bitbucket Cloud integration (posting pull request previews, deploying infrastructure…" → ✅ verified (evidence: Pulumi's Bitbucket docs state: "Pulumi Cloud integrates with Bitbucket Cloud to post pull request previews, deploy infrastructure on push, create ephemeral review stacks, and report commit statuses — the same capabilities available with…; source: https://www.pulumi.com/docs/integrations/version-control/bitbucket/)
  • L18-20 in content/docs/integrations/version-control/bitbucket.md "This page (bitbucket.md) covers the Bitbucket deployments integration specifically, and backing a Pulumi organization's membership with a Bitbucket workspace…" (also L159-161) → ✅ verified (evidence: The identity-providers page has a dedicated "Bitbucket" section stating "A Bitbucket-backed organization draws its membership from a Bitbucket workspace" and describes linking an Atlassian identity and selecting a workspace to back org…; source: repo:content/docs/administration/concepts/identity-providers.md)
  • L159-161 in content/docs/integrations/version-control/bitbucket.md "There is a documentation page 'Identity providers' at /docs/administration/concepts/identity-providers/#bitbucket describing backing a Pulumi organization's…" → ✅ verified (evidence: content/docs/administration/concepts/identity-providers.md exists with title "Identity Providers" and a "## Bitbucket" section (anchor #bitbucket) stating: "A Bitbucket-backed organization draws its membership from a Bitbucket…; source: repo:content/docs/administration/concepts/identity-providers.md)
  • L161 in content/docs/integrations/version-control/bitbucket.md "- Version control integrations — the same capabilities on GitHub, GitLab, and Azure DevOps." → ✅ verified (evidence: The linked page content/docs/integrations/version-control/_index.md states: "The native integrations — GitHub, GitLab, Bitbucket, and Azure DevOps — all provide the same core set of capabilities. Whichever provider you connect, you get…; source: repo:content/docs/integrations/version-control/_index.md)
  • L28 in content/docs/integrations/version-control/github-app.md "The Identity providers documentation page at /docs/administration/concepts/identity-providers/#github exists and covers backing a Pulumi organization's…" → ✅ verified (evidence: The page content/docs/administration/concepts/identity-providers.md exists and contains a "## GitHub" section (anchor #github) stating "A GitHub-backed organization draws its membership from a GitHub organization. Only members of that…; source: repo:content/docs/administration/concepts/identity-providers.md)
  • L30 in content/docs/integrations/version-control/github-app.md "The GitHub app requires Pulumi Cloud (app.pulumi.com) as the stack's backend." → ✅ verified (evidence: The GitHub app page states "The GitHub app requires Pulumi Cloud as your stack's backend. It does not work with self-managed backends." This is corroborated by the Deployments concepts doc, which describes Deployments (the feature the…; source: repo:content/docs/integrations/version-control/github-app.md and repo:content/docs/deployments/concepts/_index.md)
  • L30 in content/docs/integrations/version-control/github-app.md "The GitHub app does not work with self-managed (DIY) backends." → ✅ verified (evidence: The docs page itself states "The GitHub app requires Pulumi Cloud as your stack's backend. It does not work with self-managed backends." This is architecturally consistent with the Deployments concepts page, which states Pulumi…; source: repo:content/docs/integrations/version-control/github-app.md and repo:content/docs/deployments/concepts/_index.md)
  • L234 in content/docs/integrations/version-control/github-app.md "Checking whether the GitHub app has access to a repository requires navigating to Management > Version control, selecting the GitHub organization, and…" → ✅ verified (evidence: Line 234 of the same file states: "The GitHub app has access to the repository — navigate to Management > Version control, select your GitHub organization, and check the Repositories tab. If the repository is not listed…; source: repo:content/docs/integrations/version-control/github-app.md#L234)
  • L238-240 in content/docs/integrations/version-control/github-app.md "The Identity providers documentation page at /docs/administration/concepts/identity-providers/#github exists and covers backing a Pulumi organization's…" → ✅ verified (evidence: The page content/docs/administration/concepts/identity-providers.md exists and contains a "## GitHub" section (anchor #github) stating: "A GitHub-backed organization draws its membership from a GitHub organization. Only members of that…; source: repo:content/docs/administration/concepts/identity-providers.md)
  • L240 in content/docs/integrations/version-control/github-app.md "- Version control integrations — the same capabilities on GitLab, Bitbucket, and Azure DevOps." → ✅ verified (evidence: The /docs/integrations/version-control/ index page states: "The native integrations — GitHub, GitLab, Bitbucket, and Azure DevOps — all provide the same core set of capabilities. Whichever provider you connect, you get: ..." confirming…; source: repo:content/docs/integrations/version-control/_index.md)

  • Refresh this review — comment @claude #update-review. Say what you fixed, or which finding you dispute and why; both work in the same mention.
  • Ask for anything else — comment @claude with no hashtag (questions, one-off fixes). Leaves this review untouched.

Important

Please don't hide, resolve, or delete this comment! It breaks things!

📖 How pre-merge review works — the full lifecycle, short-circuits, and escape hatches.

@github-actions

github-actions Bot commented Aug 24, 2026

Copy link
Copy Markdown
Contributor
continued from previous comment
  • L21-26 in content/docs/integrations/version-control/gitlab.md "Pulumi offers the same version-control integration capabilities described on this page for GitHub, Bitbucket, and Azure DevOps, documented at…" (also L165-167) → ✅ verified (evidence: The sibling index page content/docs/integrations/version-control/_index.md states: "The native integrations — GitHub, GitLab, Bitbucket, and Azure DevOps — all provide the same core set of capabilities... Pull request previews and…; source: repo:content/docs/integrations/version-control/_index.md)
  • L22 in content/docs/integrations/version-control/gitlab.md "Pulumi Cloud integrates with GitLab to create ephemeral review stacks." → ✅ verified (evidence: The same doc states: "Pulumi Cloud integrates with GitLab to post merge request previews, deploy infrastructure on push, create ephemeral review stacks, and report commit statuses," and later details: "[Review stacks] are ephemeral cloud…; source: repo:content/docs/integrations/version-control/gitlab.md)
  • L165-167 in content/docs/integrations/version-control/gitlab.md "The 'Identity providers' page exists at /docs/administration/concepts/identity-providers/#gitlab and covers backing a Pulumi organization's membership with a…" → ✅ verified (evidence: content/docs/administration/concepts/identity-providers.md exists with a "## GitLab" section (anchor #gitlab) stating: "A GitLab-backed organization draws its membership from a top-level GitLab group... To back your organization with…; source: repo:content/docs/administration/concepts/identity-providers.md)
  • L167 in content/docs/integrations/version-control/gitlab.md "- Version control integrations — the same capabilities on GitHub, Bitbucket, and Azure DevOps." → ✅ verified (evidence: The version-control index page (/docs/integrations/version-control/) states: "The native integrations — GitHub, GitLab, Bitbucket, and Azure DevOps — all provide the same core set of capabilities," confirming the linked page and its…; source: repo:content/docs/integrations/version-control/_index.md)
  • L124 in content/docs/support/faq/pulumi-cloud.md "The Pulumi Cloud documentation page 'Identity providers' exists at /docs/administration/concepts/identity-providers/ and provides more information related to…" → ❌ contradicted (evidence: The directory listing of content/docs/administration/concepts/ in pulumi/docs contains no identity-providers.md or identity-providers/_index.md file — only organizations.md, billing-managers.md, etc. Identity provider information is…; source: gh api repos/pulumi/docs/contents/content/docs/administration/concepts)
  • L735 in data/pulumi_pricing.yaml "link: /docs/administration/concepts/identity-providers/" → ❌ contradicted (evidence: The directory listing of content/docs/administration/concepts/ in pulumi/docs contains no identity-providers.md (or identity-providers/ directory) — only organizations.md, which covers identity providers via the anchor…; source: gh api repos/pulumi/docs/contents/content/docs/administration/concepts)
  • L175 in content/docs/administration/concepts/organizations.md "The five per-provider sub-anchors deleted from this page (#changing-identity-providers, #disconnecting-identity-providers, #github-identity-provider, #gitlab-identity-provider, #bitbucket-identity-provider, #saml-single-sign-on-sso) have no remaining inbound links" → 🤷 unverifiable (evidence: A repo-wide grep of content/, data/, and layouts/ finds no page still linking to any of the deleted sub-anchors, and the parent ## Organization identity providers heading is retained so #organization-identity-providers still resolves. Inbound links from outside the repo cannot be enumerated from CI; an anchor that no longer exists silently lands the reader at the top of the page.; source: grep over content/, data/, layouts/ for the deleted anchor slugs)

📊 Editorial balance

Single-subject post; balance check N/A.

🚨 Outstanding in this PR

Nothing outstanding.

⚠️ Low-confidence

All eleven low-confidence items are closed — two fixed in 4a83a2d, nine conceded on the evidence in @jkodroff's mention. See ✅ Resolved.

Style suggestions

Optional polish from pattern-based linting — never blocking, not counted above. Take the ones that read better and ignore the rest. ✏️ marks one you can apply from the Files changed tab — use Add suggestion to batch on each, then Commit suggestions to take several in a single commit.

content/blog/p3-some-assembly-required/index.md — 2 (1 filler, 1 wordiness)
  • line 68: [style] filler — Don't start a sentence with 'So '.
  • line 68: [style] wordiness — 'a number of' is too wordy.
content/blog/using-pulumi-securely/index.md — 4 (3 spacing, 1 style)
  • line 45: [style] style — 'your Infrastructure as Code' overcapitalizes a generic concept -- use lowercase except at the start of a sentence or heading (STYLE-GUIDE.md §Headings, 'use capitalization only for proper nouns').
  • line 45: [style] spacing — 'd. S' should have one space.
  • line 45: [style] spacing — 's. S' should have one space.
  • line 45: [style] spacing — 'd. L' should have one space.

📋 Triaged verifier findings

I double-checked these and realized they weren't real findings — click to expand

All four ❌ contradicted verdicts have the same root cause: the check listed content/docs/administration/concepts/ on master, where identity-providers.md doesn't exist yet — because this PR is the commit that adds it. The file is present in the diff (+133 lines), so every one of these links resolves once merged.

  • [L68] content/blog/p3-some-assembly-required/index.md"Pulumi Cloud supports GitLab as an alternative identity provider, documented at https://www.pulumi.com/docs/administration/concepts/identity-providers/#gitlab."Spurious: the URL 404s only because the page isn't on master yet; this PR adds it, and the ## GitLab heading supplies the #gitlab anchor.

  • [L21] content/docs/administration/concepts/_index.md"There is a documentation page at /docs/administration/concepts/identity-providers/ describing identity providers that govern organization membership."Spurious: the directory listing was read from master, before this PR's new page.

  • [L124] content/docs/support/faq/pulumi-cloud.md"The Pulumi Cloud documentation page 'Identity providers' exists at /docs/administration/concepts/identity-providers/ and provides more information related to…"Spurious: same master-vs-PR listing; the page is added in this PR.

  • [L735] data/pulumi_pricing.yaml"link: /docs/administration/concepts/identity-providers/"Spurious: same master-vs-PR listing; the page is added in this PR.

These six were checked against a URL that couldn't settle the question:

  • [L68] content/docs/administration/concepts/identity-providers.md"Only members of the backing GitHub organization can belong to a GitHub-backed Pulumi organization."Mis-sourced: checked against GitHub's "creating a new organization from scratch" page, which says nothing about Pulumi organizations.

  • [L80] content/docs/administration/concepts/identity-providers.md"Subgroups cannot back a Pulumi organization; only a top-level GitLab group can."Mis-sourced: checked against GitLab's general Groups documentation, which covers the group/subgroup hierarchy but not any Pulumi-side constraint.

  • [L92] content/docs/administration/concepts/identity-providers.md"Bitbucket identities are labeled 'Atlassian' in Pulumi account settings."Mis-sourced: checked against Atlassian's "What is a workspace?" page, which can't speak to how Pulumi labels an identity in its own UI.

  • [L100] content/docs/administration/concepts/identity-providers.md"Connecting an Atlassian identity to a Pulumi account grants the Pulumi OAuth app read access to the user's Bitbucket account and workspace membership…"Mis-sourced: the fetched Confluence page returned page-shell boilerplate rather than the scopes section the anchor points at.

  • [L119] content/docs/administration/concepts/identity-providers.md"Members of a SAML-backed organization can sign in with the organization name pre-filled by visiting https://app.pulumi.com/welcome//sso."Mis-sourced: app.pulumi.com/welcome/ is a JavaScript app that returns an empty shell to a fetch, so nothing could be read from it either way.

  • [L22] content/docs/administration/guides/saml/_index.md"The identity-providers concept page at /docs/administration/concepts/identity-providers/ documents identity providers that can back a Pulumi organization's…"Mis-sourced: the check followed app.pulumi.com/signin (the pre-existing Pulumi Cloud link on that line) instead of the /docs/administration/concepts/identity-providers/ path the sentence actually asserts. That page is added by this PR.

💡 Pre-existing issues in touched files (optional)

This PR's only change to customer-managed-keys.md is a menu weight (89). These four sit on prose lines the PR doesn't touch, so they're out of scope here — @jkodroff has accepted them as such; worth a follow-up issue if they're real.

  • [L20-22] content/docs/administration/concepts/customer-managed-keys.md"Pulumi Cloud supports Customer Managed Keys (CMKs), which allow users to use their own encryption keys from an external Key Management System (KMS) to…"Pre-existing: the overview says CMKs protect "sensitive data in Pulumi Cloud," while the same page's info note narrows it to "Currently, Customer Managed Keys are only used to encrypt data in Pulumi ESC."

  • [L58] content/docs/administration/concepts/customer-managed-keys.md"Adding a Customer Managed Key enables users to use their own encryption key to protect sensitive data in Pulumi Cloud."Pre-existing: the same scope overclaim as above, restated in the "Adding" section.

  • [L49-50] content/docs/administration/concepts/customer-managed-keys.md"All new data keys responsible for encrypting data created by an organization will be encrypted with the default key."Pre-existing: Pulumi Cloud UI behavior with no public source; internally consistent with the rest of the page.

  • [L88] content/docs/administration/concepts/customer-managed-keys.md"After confirming disabling a Customer Managed Key, a banner appears showing the re-encryption process status and disappears once the process is complete."Pre-existing: same, a UI-behavior description with no public source.

✅ Resolved since last review

Fixed in 4a83a2d:

  • [L45] content/blog/using-pulumi-securely/index.md — [style-blocker] deprecated product name — 'Pulumi Service' is the former name of Pulumi Cloud. (resolved in 4a83a2d — the sentence now reads "synchronize those users and groups to Pulumi Cloud")

  • [L61] content/docs/administration/concepts/identity-providers.md — the verbatim error string "That organization is already registered." (resolved in 4a83a2d — quote removed; the note now states only that Pulumi rejects the change). The author's citation makes the fix more clearly right than the finding was: the string is built as fmt.Sprintf("That %s organization is already registered.", req.NewIdentityProvider), so the rendered message interpolates the provider and the page's quote was never verbatim to begin with.

  • [L73] content/docs/administration/concepts/identity-providers.md — the read:org scope cited a signed-in, user-specific GitHub settings URL (resolved in 4a83a2d — the scope now links GitHub's public OAuth scopes reference, verified HTTP 200, and the settings/connections URL is retained as a separate "review and grant that access" link, which is where it's actually actionable).

Conceded on the evidence in @jkodroff's mention:

  • [L3] content/docs/administration/concepts/identity-providers.md — the provider list is complete. concede: the IdentityProvider enum I flagged is not the org-backing set — ReplaceOrganizationBackendHandler accepts exactly Bitbucket, GitHub, GitLab, Pulumi, and SAML and rejects anything else, and Google reaches org backing via Google Workspace SAML. I confirmed the in-repo half independently: layouts/shortcodes/identities.html lists Google as an account sign-in identity only and carries no Azure DevOps, and accounts.md:35 independently states the same four backings ("Atlassian, GitHub, GitLab, or a SAML 2.0-compatible identity provider, such as Active Directory, Okta, or Google Workspace").

  • [L24] content/docs/administration/concepts/identity-providers.md — the Pulumi provider is the default for new organizations. concede: author confirms current Pulumi Cloud behavior; deferring to repo authority on unpublished product design.

  • [L38-39] content/docs/administration/concepts/identity-providers.md — self-lockout is unrecoverable. concede: author confirms current Pulumi Cloud behavior; deferring to repo authority on unpublished product design.

  • [L64] content/docs/administration/concepts/identity-providers.md — the Membership Requirements section is hidden for individual accounts and legacy per-stack organizations. concede: author confirms, and the individual-accounts half is independently visible in ReplaceOrganizationBackendHandler (org.AsSingleUserOrganization() != nil → "Cannot change backend for user accounts.").

  • [L95] content/docs/administration/concepts/identity-providers.md — the Bitbucket member-listing rationale. concede: author cites the rationale verbatim in organizations_backend.go:203-206, plus the up-front GetUserRoleInOrganization check and the admin/non-admin branch in org_memberships.go:1229-1233.

  • [L95] content/docs/administration/concepts/identity-providers.md — Pulumi verifies Bitbucket workspace admin status up front. concede: same citation as above; the absence of an equivalent check in getNewGitHubBackendRowFn and getNewGitLabBackendRowFn also confirms the "Unlike GitHub and GitLab" framing this pair questioned.

  • [L114-115] content/docs/administration/concepts/identity-providers.md — the SAML applier becomes organization owner. concede: author cites organizations_backend.go:79-83, where both the mechanic (changeToNewOrgOwnerID = new(requestingUser.UniqueID())) and the stated misconfiguration-recovery reason match the page.

  • [L115] content/docs/administration/concepts/identity-providers.md — the SAML preconditions, both halves. concede: validateSamlOmu rejects on !areOrgsRelated ("Requesting user belongs to other organizations") and validateUserHasNoPersonalResources rejects on ProgramCount > 0 and CountEnvironmentsForOrganization > 0. The page's "unrelated" is precise, not loose — related orgs are permitted.

  • [L175] content/docs/administration/concepts/organizations.md — the removed sub-anchors. concede: the remedy I suggested doesn't work. Browsers never transmit the URL fragment to the server, so an S3/CloudFront redirect can't key on #github-identity-provider, and /docs/administration/concepts/organizations/ still returns 200, so no redirect would fire regardless. I verified the supporting claim: across all 20 files in scripts/redirects/, 0 of 728 entries carry a fragment in the source path. The residual risk is real but unaddressable by the mechanism I proposed, and #organization-identity-providers survives with a body link to the new page.

📜 Review history

  • 2026-08-24T22:04:47Z — Link and anchor targets all resolve and menu weights are collision-free; one blocking item ('Pulumi Service' on a rewritten blog line), plus author-confirm questions on the new page's Pulumi Cloud behavior claims. (2624468)

  • 2026-08-24T23:22:19Z — Re-reviewed after fix push (1 new commit, 4a83a2d) plus a combined fix-response/dispute mention from @jkodroff. All 3 actionable items fixed and verified in the diff; all 9 remaining low-confidence items conceded. Outstanding 1 → 0, low-confidence 11 → 0. (4a83a2d)

    Evidence class on the conceded items. Nine concessions rest on citations into pulumi/pulumi-service, which is private — CI cannot replay them, so they are recorded as author-provided quotes from a local master checkout rather than as independently verified. That is the correct disposition under this skill's dispute rules: @jkodroff has write access and is asserting design intent and codebase context, which is sufficient evidence on a domain-knowledge dispute, and I have no contrary evidence to hold on. Two of the nine have in-repo corroboration I checked myself and which is recorded inline above (L3 via identities.html and accounts.md:35; L175 via the scripts/redirects/ sweep). A future reviewer re-verifying this page should treat the private-repo file:line references as the trail to follow.

    Not conceded, because they were never contested as facts: the six advisory style nits @jkodroff accepted as-is on the two historical blog posts remain listed under Style suggestions. Advisory findings are re-generated from the current head on every refresh rather than tracked, so they reappear by construction, not by disagreement — they carry no verdict and block nothing. No inline suggestion buttons are staged this run.


  • Refresh this review — comment @claude #update-review. Say what you fixed, or which finding you dispute and why; both work in the same mention.
  • Ask for anything else — comment @claude with no hashtag (questions, one-off fixes). Leaves this review untouched.

Important

Please don't hide, resolve, or delete this comment! It breaks things!

📖 How pre-merge review works — the full lifecycle, short-circuits, and escape hatches.

@github-actions github-actions Bot added review:outstanding-issues Claude review completed; outstanding has author-actionable findings and removed review:in-progress Claude review is currently running labels Aug 24, 2026
…or string

- content/blog/using-pulumi-securely/index.md: "Pulumi Service" -> "Pulumi Cloud"
  (style-blocker; line already edited by this PR).
- identity-providers.md L61: drop the quoted error message. Verified against
  pulumi-service (cmd/service/api/organizations_backend.go:115), which builds it
  as "That %s organization is already registered." with the identity provider
  interpolated, so the page's verbatim quote was inaccurate.
- identity-providers.md L73: point "`read:org` scope" at GitHub's public scopes
  reference; keep the signed-in settings URL as a separate "review and grant
  that access" link.
- organizations.md L54: drop redundant "In addition" ("In addition... you also").

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AtegdZYgiu26EUYhzJ2aJn
@github-actions github-actions Bot added review:stale New commits since last Claude review; refresh on next ready-transition or @claude mention and removed review:outstanding-issues Claude review completed; outstanding has author-actionable findings labels Aug 24, 2026
@jkodroff

Copy link
Copy Markdown
Member Author

@claude #update-review

Worked the full worklist (1 blocker, 11 low-confidence, 7 style). Fixes are in 4a83a2d71f; the rest are disputes with evidence.

Fixed

  • L45 content/blog/using-pulumi-securely/index.md (🚨 style-blocker) — "Pulumi Service" → "Pulumi Cloud".
  • L61 identity-providers.md — removed the quoted error message. This finding was correct, and more so than the review knew: the string is built as fmt.Sprintf("That %s organization is already registered.", req.NewIdentityProvider) (pulumi-service cmd/service/api/organizations_backend.go:115), so it renders as "That github.com organization is already registered." — the page's verbatim quote omitted the interpolated provider. The line now states only that Pulumi rejects the change.
  • L73 identity-providers.md — good catch on the citation. Split the links: "read:org scope" now points at GitHub's public scopes reference, and the signed-in github.com/settings/connections/... URL is retained as a separate "review and grant that access" link, where it is actually actionable.
  • L54 organizations.md — applied the one-click suggestion locally (dropped redundant "In addition"). Edited in the working tree rather than via the button, so the suggestion is stale by design.

Disputed

Note on evidence class: pulumi/pulumi-service is a private repo, so CI cannot verify the citations below. They are author-provided from a local checkout at master, quoted verbatim.

  • L95 (both items) — Bitbucket member-listing rationale. Confirmed verbatim in organizations_backend.go:203-206: "Bitbucket's API for listing organization members works differently for admins vs. non-admins. So for that reason we confirm they are a proper admin, so we can avoid trouble down the road." An up-front GetUserRoleInOrganization call then rejects non-admins with "You must be an 'admin' of the Bitbucket Workspace". getNewGitHubBackendRowFn and getNewGitLabBackendRowFn have no equivalent check, which confirms the "Unlike GitHub and GitLab" framing. See also cmd/service/model/org_memberships.go:1229-1233, which branches between listBitbucketMembersAsAdmin and listBitbucketMembersAsNonAdmin.

  • L114-115 — SAML applier becomes organization owner. Confirmed in organizations_backend.go:79-83: "We replace the 'organization owner' in the SAML case, so that if the IDPSSOMetadataDescriptor is somehow misconfigured, the current user would still have access to the organization in order to fix it." followed by changeToNewOrgOwnerID = new(requestingUser.UniqueID()). Both the mechanic and the stated reason match the page.

  • L115 — SAML preconditions, both halves. validateSamlOmu returns rest.BadRequest("Requesting user belongs to other organizations") when !areOrgsRelated(orgToCheck, org), and calls validateUserHasNoPersonalResources (cmd/service/api/users.go:1666-1682), which rejects on ProgramCount > 0 (stacks) and CountEnvironmentsForOrganization > 0 (environments). "Unrelated" is precise — related orgs are permitted.

  • L3 — provider list is complete. The IdentityProvider enum is not the org-backing set; its own doc comment says it "describes an identity system used by the Pulumi Service" and is deliberately kept separate from OrganizationKind. ReplaceOrganizationBackendHandler accepts exactly Bitbucket, GitHub, GitLab, Pulumi, and SAML, and rejects anything else with "Unknown identity provider" — no Azure DevOps or Google branch. In-repo corroboration: layouts/shortcodes/identities.html lists Google as an account sign-in identity only (and has no Azure DevOps), and accounts.md:35 independently states the same four backings. Google reaches org backing via Google Workspace SAML.

  • L24, L38-39, L64 — confirmed by the author as current Pulumi Cloud behavior (design/product knowledge, not publicly documented). L64's individual-accounts half is independently visible in ReplaceOrganizationBackendHandler: org.AsSingleUserOrganization() != nil"Cannot change backend for user accounts."

  • L175 — removed anchors. The suggested remedy is not viable: browsers never transmit the URL fragment to the server, so an S3/CloudFront redirect cannot key on #github-identity-provider. No entry in scripts/redirects/*.txt has ever had a fragment in its source path (all 20 files checked), and /docs/administration/concepts/organizations/ still returns 200, so no redirect would fire. Confirmed no in-repo links to the six anchors. Accepting the residual risk: #organization-identity-providers survives and its body links straight to the new page.

Accepted as-is

  • L68 p3-some-assembly-required ("a number of") and the four style nits on L45 using-pulumi-securely (capitalization, three double-spaces) — pre-existing prose in historical blog posts, per AGENTS.md; those lines were touched only to swap dead links.
  • The four 💡 pre-existing findings in customer-managed-keys.md — this PR's only change to that file is a menu weight bump.

@github-actions github-actions Bot added review:in-progress Claude review is currently running and removed review:stale New commits since last Claude review; refresh on next ready-transition or @claude mention labels Aug 24, 2026
@github-actions

Copy link
Copy Markdown
Contributor

🤖 Review updated on @jkodroff's request.

@github-actions github-actions Bot added review:no-blockers Claude review completed cleanly; outstanding is empty and removed review:in-progress Claude review is currently running labels Aug 24, 2026
@jkodroff
jkodroff requested a review from CamSoper August 25, 2026 00:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

domain:blog PR touches blog posts or customer stories domain:docs PR touches technical docs domain:mixed PR touches more than one domain review:no-blockers Claude review completed cleanly; outstanding is empty

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Administration: Break out organization identity providers into its own page

2 participants