Fix merge conflicts

Author: MaedahBatool

README.md

@@ -1,6 +1,6 @@
 # Sourcegraph Docs
 
-<!-- Working branch for FEB 2025 Release -->
+<!-- Working branch for April 2025 Release -->
 
 Welcome to the Sourcegraph documentation! We're excited to have you contribute to our docs. We've recently rearchitectured our docs tech stack — powered by Next.js, TailwindCSS and deployed on Vercel. This guide will walk you through the process of contributing to our documentation using the new tech stack.
 

docs.config.js

@@ -1,5 +1,5 @@
 const config = {
-	DOCS_LATEST_VERSION: '6.1'
+	DOCS_LATEST_VERSION: '6.2'
 };
 
 module.exports = config;

docs/admin/code_hosts/github.mdx

@@ -66,6 +66,8 @@ To create a GitHub App and connect it to Sourcegraph:
 
 9. (Optional) If you want to sync repositories from other organization or user namespaces and your GitHub App is set to public visibility, you can create additional installations with **Add installation**.
 
+> NOTE: When you create a GitHub App, Sourcegraph automatically sets up an [incoming webhook](/admin/config/webhooks/incoming) for the app. This webhook subscribes to events for any repository or organization the app has access to, allowing Sourcegraph to keep repository and permission data in sync with GitHub.
+
 > NOTE: If you are using [Batch Changes](/batch-changes/), you can create a GitHub App to perform [commit signing](/admin/config/batch_changes#commit-signing-for-github) (Beta).
 
 ### Multiple installations

docs/admin/code_hosts/index.mdx

@@ -58,13 +58,6 @@ We recognize there are other code hosts including CVS, SVN, and many more. Today
 - [Non-Git code hosts](/admin/code_hosts/non-git)
   - [Perforce](/admin/repo/perforce)
   - [Plastic SCM](/admin/repo/plasticscm)
-  - [Package repository hosts](/admin/code_hosts/package-repos)
-    - [JVM dependencies](/admin/code_hosts/jvm)
-    - [Go dependencies](/admin/code_hosts/go)
-    - [npm dependencies](/admin/code_hosts/npm)
-    - [Python dependencies](/admin/code_hosts/python)
-    - [Ruby dependencies](/admin/code_hosts/ruby)
-    - [Rust dependencies](/admin/code_hosts/rust)
 
 ## Rate limits
 

docs/admin/config/authorization_and_authentication.mdx

@@ -112,13 +112,7 @@ And configure the identity provider to pass the email address as the `nameID`.
 
 ### Bitbucket Server / Bitbucket Data Center authorization
 
-We do not currently support OAuth for Bitbucket Server or Bitbucket Data Center. You will need to combine permissions syncing from Bitbucket Server / Bitbucket Data Center with another authentication mechanism (SAML, built-in auth, HTTP authentication proxies). Bitbucket Server and Bitbucket Data Center only pass usernames to Sourcegraph, so you’ll need to make sure that those usernames are matched by whatever mechanism you choose to use for access.
-
-Follow the steps to [sync Bitbucket Server / Bitbucket Data Center permissions](/admin/code_hosts/bitbucket_server#repository-permissions). Then, do one of the following:
-
-1. Create the user accounts in Sourcegraph with matching usernames. (Access using `builtin` auth.)
-2. [Configure SAML authentication](/admin/auth/saml/). If you are using Bitbucket Server / Bitbucket Data Center, the `login` attribute is _not_ optional. You need to pass the Bitbucket Server username as the `login` attribute.
-3. [Configure an HTTP authentication proxy](/admin/auth/#http-authentication-proxies), passing the Bitbucket Server username value as the `usernameHeader`.
+We support authentication through OAuth for Bitbucket Server / Bitbucket Data Center. See the [Bitbucket Server auth provider docs](/admin/auth/#bitbucket-server).
 
 ### Azure DevOps Services
 

docs/admin/config/batch_changes.mdx

@@ -30,11 +30,11 @@ To restore the default behavior, you can either delete the `batchChanges.rollout
 
 Or, to put it another way:
 
-| `batchChanges.rolloutWindows` configuration | Behavior |
-|---------------------------------------------|-----------|
-| Omitted, or set to `null`                   | Changesets will be reconciled as fast as the code host allows; essentially the same as setting a single `{"rate": "unlimited"}` window. |
+| `batchChanges.rolloutWindows` configuration |                                                                                                                                           Behavior                                                                                                                                           |
+| ------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Omitted, or set to `null`                   | Changesets will be reconciled as fast as the code host allows; essentially the same as setting a single `{"rate": "unlimited"}` window.                                                                                                                                                      |
 | Set to an array (even if empty)             | Changesets will be reconciled using the rate limit in the current window using [the leaky bucket behavior described below](#leaky-bucket-rate-limiting). If no window covers the current period, then no changesets will be reconciled until a window with a non-zero [`rate`](#rate) opens. |
-| Any other value                             | The configuration is invalid, and an error will appear. |
+| Any other value                             | The configuration is invalid, and an error will appear.                                                                                                                                                                                                                                      |
 
 #### Leaky bucket rate limiting
 
@@ -171,18 +171,53 @@ For those that require a separate API call, Batch Changes will only be able to d
 
 Refer to the table below to see the levels with which each code host is supported:
 
-Code Host | Changeset property or separate API call? | Support on merge | Support on close | Note
---------- | --------- | :-: | :-: | ----
-Azure DevOps | Changeset property | ✓ | ✗ |
-Bitbucket Cloud | Changeset property | ✓ | ✓ |
-Bitbucket Server | API call | ✓ | ✓ |
-GitHub | API call | ✓ | ✓ |
-GitLab | Changeset property | ✓ | ✓ |
-Gerrit | API call | ✗ | ✓ | Requires ["delete own changes" permission](https://gerrit-review.googlesource.com/Documentation/access-control.html#category_delete_own_changes) at minimum
+   Code Host     | Changeset property or separate API call? | Support on merge | Support on close |                                                                            Note
+---------------- | ---------------------------------------- | :--------------: | :--------------: | -----------------------------------------------------------------------------------------------------------------------------------------------------------
+Azure DevOps     | Changeset property                       |        ✓         |        ✗         |
+Bitbucket Cloud  | Changeset property                       |        ✓         |        ✓         |
+Bitbucket Server | API call                                 |        ✓         |        ✓         |
+GitHub           | API call                                 |        ✓         |        ✓         |
+GitLab           | Changeset property                       |        ✓         |        ✓         |
+Gerrit           | API call                                 |        ✗         |        ✓         | Requires ["delete own changes" permission](https://gerrit-review.googlesource.com/Documentation/access-control.html#category_delete_own_changes) at minimum
 
-## Commit signing for GitHub
+## Commit signing
 
-<Callout type="note"> The feature is currently in Beta stage and supported on Sourcegraph versions 5.1 or more.</Callout>
+Batch Changes supports commit signing with both GitHub apps and with SSH keys.
+
+### Commit signing with SSH keys (GitLab and GitHub)
+
+<Callout type="note">Commit signing with SSH keys is currently Experimental and is supported only with Sourcegraph v6.2 or more.</Callout>
+
+Commit signing with SSH keys can only be combined with a personal or fine-grained access token.
+
+Sourcegraph can be configured to sign commits using SSH keys with user and site admin credentials.
+
+To enable **commit signing for your Batch Changes user**, navigate to **Settings > Batch Changes** and click **Add credentials** for a GitHub or GitLab code host.
+
+![List of code hosts with an arrow pointing to add credential](https://storage.googleapis.com/sourcegraph-assets/docs/images/batch_changes/2025/code_host_add_credential.png)
+
+If you already have a credential for the given code host, remove it first.
+
+Enter your personal access token, and check the "Sign commits on this code host" box. This will add a step to the setup flow. Click "Next" and wait for Batch Changes to verify the access token.
+
+![The modal for adding a credential with an arrow pointing to the checkbox for commit signing](https://storage.googleapis.com/sourcegraph-assets/docs/images/batch_changes/2025/setup_commit_signing_checkbox.png)
+
+Once the credential is added, you can copy the public SSH key Batch Changes will use to sign commits. You can view the public key anytime by clicking **View Credentials**.
+
+![The modal displays the ssh key used for commit signing](https://storage.googleapis.com/sourcegraph-assets/docs/images/batch_changes/2025/setup_commit_signing_view_ssh_key.png)
+
+Add this public SSH key to your [GitHub](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account) or [GitLab](https://docs.gitlab.com/user/ssh/#add-an-ssh-key-to-your-gitlab-account) account.
+Make sure you add it as a signing key.
+
+![Add the key to your code host as a signing key](https://storage.googleapis.com/sourcegraph-assets/docs/images/batch_changes/2025/github_add_signing_key.png)
+
+To enable **commit signing as a site admin**, navigate to **Site Admin > Section: Batch Changes > Settings** and click **Add credentials** for a GitHub or GitLab code host. The rest of the setup is the same as above.
+
+![Site admin settings for batch changes](https://storage.googleapis.com/sourcegraph-assets/docs/images/batch_changes/2025/batch_changes_site_admin_settings.png)
+
+### Commit signing with GitHub apps
+
+<Callout type="note">Commit signing with GitHub apps is currently in Beta and is supported with Sourcegraph v5.1 or more.</Callout>
 
 Sourcegraph can be configured to [sign commits pushed to GitHub](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification) using a GitHub App. Commit signing prevents tampering by unauthorized parties and provides a way to ensure that commits pushed to branches created by Batch Changes actually do come from Sourcegraph. Enabling commit signing for Batch Changes can also help pass checks in build systems or CI/CD pipelines that require that all commits are signed and verified before they can be merged.
 
@@ -306,3 +341,32 @@ When a user is deleted, their Batch Changes become inaccessible in the UI but th
 This allows recovering the Batch Changes if the user is restored.
 
 However, if the user deletion is permanent, deleting both account and data, then the associated Batch Changes are also permanently deleted from the database. This frees storage space and removes dangling references.
+
+## Batch Spec Library
+
+<Callout type="note"> Batch Spec Library is currently in Experimental.</Callout>
+
+The Batch Spec Library is a collection of Batch Specs that can be used to create Batch Changes. Sourcegraph provides a few Batch Specs out of the box.
+
+Site admins can manage the library through the GraphQL mutations `createBatchSpecLibraryRecord`, `updateBatchSpecLibraryRecord`, and `deleteBatchSpecLibraryRecord`. Use the query `batchSpecLibrary` to list all available Batch Spec examples.
+
+```graphql
+createBatchSpecLibraryRecord(name: "example", spec: "version: 2\nname: example") {
+  id
+}
+
+updateBatchSpecLibraryRecord(id: "QmF0Y2hTcGVjTGlicmFyeVJlY29yZDo4", name: "example-2", spec: "version: 2\nname: example-2") {
+  id
+}
+
+deleteBatchSpecLibraryRecord(id: "QmF0Y2hTcGVjTGlicmFyeVJlY29yZDo4") {
+  alwaysNil
+}
+
+batchSpecLibrary(first: 100) {
+  nodes {
+    id
+    name
+  }
+}
+```

docs/admin/deploy/kubernetes/index.mdx

@@ -938,7 +938,7 @@ When all pods have restarted and show as Running, you can browse to your Sourceg
 - Check the `Site Admin > Updates` page to determine [upgrade readiness](/admin/updates/#upgrade-readiness).
 
 **Step 2:**
-> <Callout type="warning">The Kubernetes Helm deployment type does not support MVU from Sourcegraph `v5.9.45` versions and earlier to Sourcegraph `v6.0.0`. Admins seeking to upgrade to Sourcegraph `v6.0.0` should upgrade to `v5.10.3940` or `v5.11.6271` and then use the standard upgrade procedure to get to `v6.0.0`. This is because migrator v6.0.0 will no longer connect to Postgres 12 databases. For more info see our [PostgreSQL upgrade docs](/admin/postgres#requirements).</Callout>
+> <Callout type="warning">The Kubernetes Helm deployment type does not support MVU from Sourcegraph `v5.9.45` versions and earlier to ANY version `v6.0.x` or later. Admins seeking to upgrade to any Sourcegraph version `v6.0.x` or later (including `v6.1.x`, `v6.2.x`, etc.) must first upgrade to `v5.10.3940` or `v5.11.6271` and then use the standard upgrade procedure to get to their target version. This is because migrator in all versions from `v6.0.0` onwards will no longer connect to Postgres 12 databases. For more info see our [PostgreSQL upgrade docs](/admin/postgres#requirements).</Callout>
 
 Scale down `deployments` and `statefulSets` that access the database, _this step prevents services from accessing the database while schema migrations are in process._
 The following services must have their replicas scaled to 0:

docs/admin/how-to/upgrade-postgres-12-16-builtin-dbs.mdx

@@ -82,6 +82,28 @@ $ kubectl apply -f deploy-sourcegraph-k8s/base/sourcegraph/pgsql/pgsql.StatefulS
 
 ## Helm
 
-To upgrade builtin containers in Helm admins must update their instance to v5.11.6271 via the [helm multi-version upgrade procedure](/admin/deploy/kubernetes#multi-version-upgrade-procedure) or standard upgrade procedure. This is because `helm upgrade` doesn't support just the DBs in a chart.
+When using the in-cluster PostgreSQL databases included in the Sourcegraph Helm chart, database upgrades are integrated with the overall application upgrade process and there is no mechanism to upgrade only the PostgreSQL containers independently. Therefore, the PostgreSQL upgrade must be performed as part of a full Sourcegraph version upgrade.
 
-<Callout type="warning"> In Sourcegraph version 6.0.0 Sourcegraph services will no longer be able to connect to a Postgres 12 database. This means at and after Sourcegraph 6.0.0, migrator will not be connect to older versions to execute the `upgrade` command. </Callout>
+For production deployments, we recommend using external PostgreSQL databases, which allows for more flexible database management outside the Helm deployment lifecycle.
+
+### Required Upgrade Path
+
+<Callout type="warning">Sourcegraph versions `v6.0.x` and later require PostgreSQL 16 and will not connect to PostgreSQL 12 databases. This means any direct upgrade from versions earlier than `v5.10.3940` to any version `v6.0.x` or later will fail because the migrator in `v6.0.x` and later cannot connect to PostgreSQL 12 to perform the upgrade.</Callout>
+
+To safely upgrade PostgreSQL in Helm deployments:
+
+1. **First upgrade to an intermediate version**:
+   - Upgrade to either Sourcegraph `v5.10.3940` or `v5.11.6271` using the [helm multi-version upgrade procedure](/admin/deploy/kubernetes#multi-version-upgrade-procedure) or [standard upgrade procedure](/admin/deploy/kubernetes#standard-upgrades)
+   - These specific versions include the necessary PostgreSQL upgrade scripts to safely migrate from PG12 to PG16
+
+2. **Verify the PostgreSQL upgrade** (optional):
+   - You can verify the PostgreSQL version has been successfully upgraded by connecting to the database:
+     ```bash
+     kubectl exec -it pgsql -- psql -U sg -c "SELECT version();"
+     ```
+   - The output should show PostgreSQL 16.x
+
+3. **Proceed to target version**:
+   - Once PostgreSQL has been upgraded to version 16, you can safely upgrade to your target version (`v6.0.x` or later) using the standard upgrade procedure
+
+For any issues during the PostgreSQL upgrade process, please contact [email protected].