Repo sync

content/actions/concepts/security/openid-connect.md

@@ -88,6 +88,9 @@ The following example OIDC token uses a subject (`sub`) that references a job en
 }
 ```
 
+> [!NOTE]
+> The `sub` claim in this example uses the previous format. Repositories created after July 15, 2026 use an immutable default subject format that includes owner and repository IDs (not available on {% data variables.product.prodname_ghe_server %}). For more information, see [AUTOTITLE](/actions/reference/security/oidc#immutable-subject-claims).
+
 {% ifversion ghec %}
 
 ## Establishing OIDC trust with your cloud provider

content/code-security/concepts/supply-chain-security/index.md

@@ -8,6 +8,7 @@ versions:
 contentType: concepts
 redirect_from:
   - /code-security/supply-chain-security/understanding-your-software-supply-chain
+  - /code-security/concepts/supply-chain-security/automatic-dependabot-access-to-github-registries
 children:
   - supply-chain-security
   - open-source-license-compliance
@@ -23,7 +24,6 @@ children:
   - dependabot-pull-requests
   - multi-ecosystem-updates
   - about-the-dependabot-yml-file
-  - automatic-dependabot-access-to-github-registries
   - dependabot-auto-triage-rules
   - dependabot-on-actions
   - dependabot-job-logs

content/code-security/how-tos/secure-at-scale/configure-organization-security/manage-usage-and-access/giving-org-access-private-registries.md

@@ -81,19 +81,6 @@ Any private registries used by the build must also be accessible to the workflow
 
 When you configure access to one or more private registries, {% data variables.product.prodname_dependabot %} can propose pull requests to upgrade a vulnerable dependency or to maintain a dependency, see [AUTOTITLE](/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-access-to-private-registries) and [AUTOTITLE](/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-private-registries).
 
-{% ifversion org-automatic-registry-access %}
-
-### Automatic access to {% data variables.product.github %}-hosted registries
-
-For packages stored in {% data variables.product.prodname_registry %} and {% data variables.product.prodname_container_registry %}, {% data variables.product.prodname_dependabot %} can authenticate automatically without {% data variables.product.pat_generic_plural %} or `dependabot.yml` registry configuration. 
-
-{% data variables.product.prodname_dependabot %} uses its `GITHUB_TOKEN` to request read access, reusing the same package access grants that {% data variables.product.prodname_actions %} workflows use.
-
-To enable this, grant the repository **Read** access to each package in the package settings. Once access is granted, {% data variables.product.prodname_dependabot %} can pull from those packages automatically, and you can remove any {% data variables.product.pat_generic %}-based registry entries you previously configured for them.
-
-See [AUTOTITLE](/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-access-to-private-registries#configuring-private-github-hosted-registries).
-{% endif %}
-
 {% ifversion org-private-registry-oidc %}
 
 ### Configuring OIDC authentication for a private registry

content/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-access-to-private-registries.md

@@ -29,41 +29,8 @@ For specific ecosystems, you can configure {% data variables.product.prodname_de
 
 {% ifversion dependabot-on-actions-self-hosted %}To allow {% data variables.product.prodname_dependabot %} access to registries hosted privately or restricted to internal networks, configure {% data variables.product.prodname_dependabot %} to run on {% data variables.product.prodname_actions %} self-hosted runners. For more information, see [AUTOTITLE](/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-on-self-hosted-runners).{% endif %}
 
-{% ifversion org-automatic-registry-access %}
-
-## Configuring private {% data variables.product.github %}-hosted registries
-
-For packages stored in {% data variables.product.prodname_registry %} or {% data variables.product.prodname_container_registry %}, {% data variables.product.prodname_dependabot %} can authenticate automatically using its `GITHUB_TOKEN`. This uses the same "Manage Actions access" grants that {% data variables.product.prodname_actions %} workflows use. No {% data variables.product.pat_generic_plural %} or `dependabot.yml` registry entries are required.
-
-The `dependabot.yml` registry configuration using {% data variables.product.pat_generic_title_case %}-based registry entries and described in [Configuring private third-party registries](#configuring-private-third-party-registries) is still required for third-party private registries (such as Artifactory, Azure Artifacts, or Nexus).
-
-To grant {% data variables.product.prodname_dependabot %} access to a private package:
-
- {% data reusables.package_registry.package-settings-from-org-level %}
- {% data reusables.package_registry.package-settings-option %}
- {% data reusables.package_registry.package-settings-actions-access %}
- 1. {% data reusables.package_registry.package-settings-add-repo %}. 
-    Search for the repository where {% data variables.product.prodname_dependabot %} runs, and select it.
- {% data reusables.package_registry.package-settings-actions-access-role-repo %}
-    Select **Read** as the access level. {% data variables.product.prodname_dependabot %} only needs read access to pull packages.
-
-You need to repeat these steps for each private package that you want {% data variables.product.prodname_dependabot %} to access.
-
-Once access is granted, {% data variables.product.prodname_dependabot %} can pull from those packages automatically. You can remove any {% data variables.product.pat_generic %}-based registry entries in `dependabot.yml` that you previously configured for these packages.
-
-> [!NOTE]
-> This method works for every {% data variables.product.prodname_registry %} ecosystem that {% data variables.product.prodname_dependabot %} supports, including container images in {% data variables.product.prodname_container_registry %}.
-
-For more information about how automatic access works, see [AUTOTITLE](/code-security/concepts/supply-chain-security/automatic-dependabot-access-to-github-registries). For more information about package access settings, see [AUTOTITLE](/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-workflow-access-to-your-package).
-
-## Configuring private third-party registries
-
-{% else %}
-
 ## Configuring private registries
 
-{% endif %}
-
 {% ifversion org-private-registry %}
 
 You can configure {% data variables.product.prodname_dependabot %}'s access to private registries at the org-level.

content/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-private-registries.md

@@ -109,12 +109,6 @@ The snippet below shows a `dependabot.yml` file configuration that uses a token.
 
 Docker supports using a username and password for registries. For more information, see `docker-registry` in [AUTOTITLE](/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-access-to-private-registries#docker-registry).
 
-{% ifversion org-automatic-registry-access %}
-
-For images stored in {% data variables.product.prodname_container_registry %}, you can grant your repository **Read** access in the package settings instead of configuring credentials in your `dependabot.yml` file. See [AUTOTITLE](/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-access-to-private-registries#configuring-private-github-hosted-registries).
-
-{% endif %}
-
 Snippet of `dependabot.yml` file using a username and password.
 
 {% raw %}

content/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility.md

@@ -116,12 +116,6 @@ The specified repository does not need to be the repository where the source cod
 If you publish a package that is linked to a repository, {% data variables.product.prodname_actions %} workflows in the linked repository automatically get access to the package, unless your organization has disabled the automatic inheritance of access permissions. For more information, see [About inheritance of access permissions](#about-inheritance-of-access-permissions) above.
 {% endif %}
 
-{% ifversion org-automatic-registry-access %}
-
-Granting a repository access here also allows {% data variables.product.prodname_dependabot %} to pull from this package automatically, without requiring {% data variables.product.pat_generic_plural %} or `dependabot.yml` registry configuration. See [AUTOTITLE](/code-security/concepts/supply-chain-security/automatic-dependabot-access-to-github-registries).
-
-{% endif %}
-
 > [!NOTE]
 > * Syncing your package with a repository {% data variables.package_registry.package-settings-actions-access-menu %} is different than connecting your package to a repository. For more information about linking a repository to your package, see [AUTOTITLE](/packages/learn-github-packages/connecting-a-repository-to-a-package).
 > * You can choose to limit permissions to workflow jobs using the `permissions` key and `packages` scope. For more information, see [AUTOTITLE](/actions/tutorials/authenticate-with-github_token#modifying-the-permissions-for-the-github_token).

content/pull-requests/get-started/about-stacked-prs.md

@@ -113,7 +113,7 @@ You can merge your entire stack, a single pull request, or a portion of the stac
 Stacks support merge commit, squash, and rebase merge methods, and they are merge-queue aware. The resulting commit history is the same as merging each pull request individually, starting from the bottom.
 
 > [!NOTE]
-> If you merge via the API and want to use stacked pull requests, you'll need to update to use the new merge API for stacks. See [AUTOTITLE](/pull-requests/reference/stacked-pull-requests-rest-and-graphql-apis).
+> If you merge via the API and want to use stacked pull requests, you'll need to update to use the new merge API for stacks. See [AUTOTITLE](/rest/pulls/pulls?apiVersion=2026-03-10#merge-a-pull-request-asynchronously).
 
 ## Next steps
 

content/pull-requests/how-tos/merge-and-close-pull-requests/merging-stacked-pull-requests.md

@@ -27,7 +27,7 @@ The merge box for a stacked pull request shows the status of the entire stack, n
 If the stack is not linear, for example, after changes were pushed to a lower branch or after the trunk moved ahead, a **Rebase stack** button will appear in the merge box and you'll need to rebase the stack before you can merge.
 
 > [!NOTE]
-> * If you merge via the API and want to use stacked pull requests, you'll need to update your code to use the new merge API for stacks. See [AUTOTITLE](/pull-requests/reference/stacked-pull-requests-rest-and-graphql-apis).
+> * If you merge via the API and want to use stacked pull requests, you'll need to update your code to use the new merge API for stacks. See [AUTOTITLE](/rest/pulls/pulls?apiVersion=2026-03-10#merge-a-pull-request-asynchronously).
 > * Auto-merge is not supported for stacked pull requests.
 
 ## Merging using a merge queue

content/pull-requests/reference/stacked-pull-requests-rest-and-graphql-apis.md

@@ -24,7 +24,7 @@ The REST API exposes stacked pull requests in two ways:
 * **The Stacks API.** A dedicated set of endpoints to list, read, create, extend, and dissolve stacks. This is the surface for creating and modifying stacks.
 
 > [!NOTE]
-> If you merge via the API and want to use stacked pull requests, you'll need to update your code to use the new merge API for stacks.
+> If you merge via the API and want to use stacked pull requests, you'll need to update your code to use the new merge API for stacks. See [AUTOTITLE](/rest/pulls/pulls?apiVersion=2026-03-10#merge-a-pull-request-asynchronously).
 
 For endpoints, parameters, and schemas, see [AUTOTITLE](/rest/pulls/pulls).
 

src/graphql/data/fpt/changelog.json

@@ -1,4 +1,17 @@
 [
+  {
+    "schemaChanges": [
+      {
+        "title": "The GraphQL schema includes these changes:",
+        "changes": [
+          "<p>Enum value <code>GITLAB</code> was added to enum <code>MigrationSourceType</code></p>"
+        ]
+      }
+    ],
+    "previewChanges": [],
+    "upcomingChanges": [],
+    "date": "2026-07-31"
+  },
   {
     "schemaChanges": [
       {

src/graphql/data/fpt/schema-migrations.json

@@ -898,6 +898,10 @@
         {
           "name": "GITHUB_ARCHIVE",
           "description": "<p>A GitHub Migration API source.</p>"
+        },
+        {
+          "name": "GITLAB",
+          "description": "<p>A GitLab migration source.</p>"
         }
       ],
       "category": "migrations"

src/graphql/data/fpt/schema.docs.graphql

@@ -26354,6 +26354,11 @@ enum MigrationSourceType @docsCategory(name: "migrations") {
   A GitHub Migration API source.
   """
   GITHUB_ARCHIVE
+
+  """
+  A GitLab migration source.
+  """
+  GITLAB
 }
 
 """

src/graphql/data/ghec/schema-migrations.json

@@ -898,6 +898,10 @@
         {
           "name": "GITHUB_ARCHIVE",
           "description": "<p>A GitHub Migration API source.</p>"
+        },
+        {
+          "name": "GITLAB",
+          "description": "<p>A GitLab migration source.</p>"
         }
       ],
       "category": "migrations"

src/graphql/data/ghec/schema.docs.graphql

@@ -26354,6 +26354,11 @@ enum MigrationSourceType @docsCategory(name: "migrations") {
   A GitHub Migration API source.
   """
   GITHUB_ARCHIVE
+
+  """
+  A GitLab migration source.
+  """
+  GITLAB
 }
 
 """