diff --git a/docs/admin/access-control/batch-changes.mdx b/docs/admin/access-control/batch-changes.mdx index 4c9d40bbd..adc53c5ed 100644 --- a/docs/admin/access-control/batch-changes.mdx +++ b/docs/admin/access-control/batch-changes.mdx @@ -1,6 +1,6 @@ # Access control for Batch Changes -Granular controls for who can access [Batch Changes](/batch-changes/) can be configured by site admins by tuning the roles assigned to users and the permissions granted to those roles. This page describes the permission types available for Batch Changes, and whether they are granted by default to the **User** [system role](/admin/access-control#system-roles). All permissions are granted to the **Site Administrator** system role by default. +Granular controls for who can access [Batch Changes](/batch-changes/) can be configured by administrators by tuning the roles assigned to users and the permissions granted to those roles. This page describes the permission types available for Batch Changes, and whether they are granted by default to the **User** [system role](/admin/access-control#system-roles). All permissions are granted to the **Administrator** system role by default. | Name | Description | Granted to **User** by default? | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-----------------------------: | @@ -9,9 +9,9 @@ Granular controls for who can access [Batch Changes](/batch-changes/) can be con | `batch_changes:agent_read` | | ✓ | | `batch_changes:agent_write` | | ✓ | -These permissions gate access to the Batch Changes feature as a whole. Within a batch change, what a user can see and do is further limited by the batch change's [permission levels](/batch-changes/permissions-in-batch-changes#permission-levels-for-batch-changes) and by their [repository permissions](/batch-changes/permissions-in-batch-changes#repository-permissions-for-batch-changes). Merging changesets can additionally be restricted to site admins with the `batchChanges.restrictMergeToAdmins` [site configuration](/batch-changes/permissions-in-batch-changes#restricting-merges-to-site-admins) property. +These permissions gate access to the Batch Changes feature as a whole. Within a batch change, what a user can see and do is further limited by the batch change's [permission levels](/batch-changes/permissions-in-batch-changes#permission-levels-for-batch-changes) and by their [repository permissions](/batch-changes/permissions-in-batch-changes#repository-permissions-for-batch-changes). Merging changesets can additionally be restricted to administrators with the `batchChanges.restrictMergeToAdmins` [advanced configuration](/batch-changes/permissions-in-batch-changes#restricting-merges-to-site-admins) property. - The site configuration property `batchChanges.restrictToAdmins` is deprecated and has no effect. - To restrict Batch Changes to site admins, remove the `batch_changes:read` and `batch_changes:write` permissions from the **User** role instead. + The advanced configuration property `batchChanges.restrictToAdmins` is deprecated and has no effect. + To restrict Batch Changes to administrators, remove the `batch_changes:read` and `batch_changes:write` permissions from the **User** role instead. diff --git a/docs/admin/access-control/index.mdx b/docs/admin/access-control/index.mdx index 01744edac..e79d1b70b 100644 --- a/docs/admin/access-control/index.mdx +++ b/docs/admin/access-control/index.mdx @@ -7,7 +7,7 @@ This page refers to in-product permissions, which determine who can, for - example, create a batch change, or who is a site admin. This is *not* the + example, create a batch change, or who is an administrator. This is *not* the same as [repository permissions](/admin/permissions/), which enforces the same repository access on Sourcegraph as your code host. @@ -18,13 +18,13 @@ Sourcegraph uses [Role-Based Access Control (RBAC)](https://en.wikipedia.org/wik ![Role management page](https://sourcegraphstatic.com/docs/images/administration/access_control/managing_roles_permissions_dark.png) -Site admins can control which features each type of user has access to by creating custom roles and assigning permissions to them. You can see all available roles and create new ones under **Site admin > Users & auth > Roles**. +Administrators can control which features each type of user has access to by creating custom roles and assigning permissions to them. You can see all available roles and create new ones under **Administration > Users & auth > Roles**. ### System roles Every Sourcegraph instance ships with two built-in system roles: -- **Site Administrator**: This role is granted to any user who is promoted to site admin. It always has all features and permissions of Sourcegraph granted to it and the set of permissions cannot be modified. +- **Administrator**: This role is granted to any user who is promoted to administrator. It always has all features and permissions of Sourcegraph granted to it and the set of permissions cannot be modified. - **User:** This role is granted to every user of the Sourcegraph instance and cannot be unassigned. By default, it has all features and permissions of Sourcegraph granted to it, but _the set of permissions can be modified_. ### Creating a new role and assigning it permissions @@ -33,7 +33,7 @@ To create a new role, click the **+ Create role** button. Give the role a unique ### Editing permissions for an existing role -> NOTE: The **Site Administrator** role cannot be modified. +> NOTE: The **Administrator** role cannot be modified. To edit the permissions granted to a role, click the role to expand it, then select the new set of permissions you want to grant to it. Then click **Update** to save your changes. @@ -55,9 +55,9 @@ To delete a role, click the **Delete** button on it. You will be prompted to con Built-in system roles cannot be assigned this way. -Site admins can manage which roles are assigned to which users from **Site admin > Users & auth > Users**. To view or edit a user's roles, click the triple dots to open the context menu for that user, then click **Manage roles**. This will open a modal dialog where you can see the user's current roles, assign new ones, or unassign current ones. You can type in the input field to search roles by name. Click **Update** to save any changes, or **Cancel** to discard. Note that system roles cannot be revoked or assigned via this modal. +Administrators can manage which roles are assigned to which users from **Administration > Users & auth > Users**. To view or edit a user's roles, click the triple dots to open the context menu for that user, then click **Manage roles**. This will open a modal dialog where you can see the user's current roles, assign new ones, or unassign current ones. You can type in the input field to search roles by name. Click **Update** to save any changes, or **Cancel** to discard. Note that system roles cannot be revoked or assigned via this modal. -To assign the **Site Administrator** system role to a user, open the same context menu from the triple dots, then click **Promote to site admin**. To unassign the **Site Administrator** role, open the same context menu from the triple dots, then click **Revoke site admin**. +To assign the **Administrator** system role to a user, open the same context menu from the triple dots, then click **Promote to administrator**. To unassign the **Administrator** role, open the same context menu from the triple dots, then click **Revoke administrator**. The **User** system role is automatically assigned to all users and cannot be revoked. diff --git a/docs/admin/audit-log.mdx b/docs/admin/audit-log.mdx index 82d6574a6..7ec8be837 100644 --- a/docs/admin/audit-log.mdx +++ b/docs/admin/audit-log.mdx @@ -60,7 +60,7 @@ The audit log captures a wide range of security-relevant events including: - **Authentication Events** - Login attempts, access token usage, password changes, and sign-out events - **Authorization Events** - Permission changes, role modifications, and access control updates - **User Management** - User creation, modification, deletion, and email verification -- **Configuration Changes** - Site configuration updates, external service modifications +- **Configuration Changes** - Advanced configuration updates, external service modifications - **Repository Access** - Repository access events and gitserver requests - **API Usage** - GraphQL requests and outbound API calls - **Code Host Integration** - External service configuration and webhook events @@ -105,11 +105,11 @@ Below is a comprehensive list of currently audited entities and their associated ### Target audience -Security specialists. We expect these to ingest the logs into their SIEM tools and define alert policies as they see fit. Site admins are currently not the target audience, but we'll likely offer an easy-to-use in-app audit log. +Security specialists. We expect these to ingest the logs into their SIEM tools and define alert policies as they see fit. Administrators are currently not the target audience, but we'll likely offer an easy-to-use in-app audit log. ## Configuring -The audit log is currently configured using the site config. Here's the corresponding entry: +The audit log is currently configured using the advanced configuration. Here's the corresponding entry: ``` "log": { @@ -219,7 +219,7 @@ The `audit.actor` node carries ID of the user who performed the action (`actorUI 1. Grab the user ID from the audit log 1. Base64 [encode](https://www.base64encode.org) the ID with a "User:" prefix. For example, for Actor with ID 71 use `User:71`, which encodes to `VXNlcjo3MQ==` -1. Navigate to Site Admin -> API Console and run the query below +1. Navigate to Administration -> API Console and run the query below 1. Find the corresponding user by searching the query results for the encoded ID from above GraphQL query: diff --git a/docs/admin/auth/builtin.mdx b/docs/admin/auth/builtin.mdx index 521d0f0f5..247921ca2 100644 --- a/docs/admin/auth/builtin.mdx +++ b/docs/admin/auth/builtin.mdx @@ -1,24 +1,24 @@ # Builtin password authentication -The [`builtin` auth provider](/admin/config/site-config#builtin-password-authentication) manages user accounts inside Sourcegraph. It supports user signup, login, and password reset. This is the simplest provider type to set up, and is the default auth provider on a fresh installation for the first user so they can create an account and become site admin. +The [`builtin` auth provider](/admin/config/site-config#builtin-password-authentication) manages user accounts inside Sourcegraph. It supports user signup, login, and password reset. This is the simplest provider type to set up, and is the default auth provider on a fresh installation for the first user so they can create an account and become administrator. Use this auth provider, if you have no organizational requirements to use a SSO provider. When enabled, users will be able to login using username/password combinations from the login screen. -Signup can either be allowed to all users, the site admin can provision accounts, or new users can request an account. +Signup can either be allowed to all users, the administrator can provision accounts, or new users can request an account. ![Login form for builtin authentication](https://storage.googleapis.com/sourcegraph-assets/docs/images/admin/auth/login_signup.png) If Sourcegraph is running on a free license all users will be created as - site admins. Learn more about license settings on our [pricing + administrators. Learn more about license settings on our [pricing page](https://about.sourcegraph.com/pricing). ## Enabling this authentication provider -Add the following section to your site configuration: +Add the following section to your advanced configuration: ```json { @@ -63,19 +63,19 @@ When `allowSignup` is not set, or set to `false`, users will see a request accou configurations. -New users can submit a form and site admins will see the request in the navbar on the instance, where they can approve or reject the requests. +New users can submit a form and administrators will see the request in the navbar on the instance, where they can approve or reject the requests. ![List of pending access requests for admin to approve](https://storage.googleapis.com/sourcegraph-assets/docs/images/admin/auth/pending-access-requests.png) ## Disable account requests from users -The account request feature can be disabled by setting `"auth.accessRequest": { "enabled": false }`. When disabled, new user accounts can only be created by the site admin manually. +The account request feature can be disabled by setting `"auth.accessRequest": { "enabled": false }`. When disabled, new user accounts can only be created by the administrator manually. ## Creating builtin authentication users Users can be created for builtin password authentication in several ways: -- through the site admin page `/site-admin/users/new` +- through the Administration page `/site-admin/users/new` - through users [signing up](#allow-all-new-users-to-sign-up-to-your-sourcegraph-instance) - through the `createUser` mutation in the GraphQL API - through [`src users create`](/cli/references/users/create) @@ -84,9 +84,9 @@ When [SMTP is enabled](/self-hosted/email), special behaviours apply to whether ## Account lockout -Password reset links expire after 4 hours by default - this can be configured in site configuration with the [`auth.passwordResetLinkExpiry`](/admin/config/site-config#auth-passwordResetLinkExpiry) field. +Password reset links expire after 4 hours by default - this can be configured in advanced configuration with the [`auth.passwordResetLinkExpiry`](/admin/config/site-config#auth-passwordResetLinkExpiry) field. -Account will be locked out for 30 minutes after 5 consecutive failed sign-in attempts within one hour for the builtin authentication provider. The threshold and duration of lockout and consecutive periods can be customized via `"auth.lockout"` in the site configuration: +Account will be locked out for 30 minutes after 5 consecutive failed sign-in attempts within one hour for the builtin authentication provider. The threshold and duration of lockout and consecutive periods can be customized via `"auth.lockout"` in the advanced configuration: ```json { @@ -102,7 +102,7 @@ Account will be locked out for 30 minutes after 5 consecutive failed sign-in att } ``` -To enabled self-serve account unlock through emails, add the following lines to your site configuration: +To enabled self-serve account unlock through emails, add the following lines to your advanced configuration: ```json { diff --git a/docs/admin/auth/index.mdx b/docs/admin/auth/index.mdx index d2deb2b58..6661c8446 100644 --- a/docs/admin/auth/index.mdx +++ b/docs/admin/auth/index.mdx @@ -34,7 +34,7 @@ The following methods are supported for sign up and sign in: - [HTTP authentication proxies](#http-authentication-proxies) - [Username header prefixes](#username-header-prefixes) -The authentication providers are configured in the [`auth.providers`](/admin/config/site-config#authentication-providers) site configuration option. +The authentication providers are configured in the [`auth.providers`](/admin/config/site-config#authentication-providers) advanced configuration option. ## Programmatic authentication @@ -91,7 +91,7 @@ GitHub Enterprise, create one on your instance, not GitHub.com). Set the followi > organization (rather than your personal account) or by [following these > instructions](https://help.github.com/articles/approving-oauth-apps-for-your-organization/). -Then add the following lines to your site configuration: +Then add the following lines to your advanced configuration: ```json { @@ -226,7 +226,7 @@ Sourcegraph instance: Write access is required for Batch Changes. -Then add the following lines to your site configuration: +Then add the following lines to your advanced configuration: ```json { @@ -335,7 +335,7 @@ Sourcegraph instance: - `Repositories`: `Read` (more information in [repository permissions section](/admin/permissions)) After the consumer is created, you will need the `Key` and the `Secret`, which can be found by expanding OAuth consumer in the list. -Then add the following lines to your [site configuration](/admin/config/site-config): +Then add the following lines to your [advanced configuration](/admin/config/site-config): ```json { @@ -363,7 +363,7 @@ Sourcegraph instance: - `Repositories`: `Read` (more information in [repository permissions section](/admin/permissions)) After the link is created, you will need to copy the `Client ID` and the `Client Secret`. -Then add the following lines to your [site configuration](/admin/config/site-config): +Then add the following lines to your [advanced configuration](/admin/config/site-config): ```json { @@ -387,7 +387,7 @@ Replace the `clientID` and `clientSecret` values with the values from your Bitbu Beta To enable users to add Gerrit credentials and verify their access to repositories on Sourcegraph, -add the following lines to your [site configuration](/admin/config/site-config): +add the following lines to your [advanced configuration](/admin/config/site-config): ```json { @@ -424,7 +424,7 @@ To configure Sourcegraph to authenticate users via OpenID Connect: 1. Create a new OpenID Connect client in the external service (such as one of those listed above). - **Redirect/callback URI:** `https://sourcegraph.example.com/.auth/callback` (replace `https://sourcegraph.example.com` with the value of the `externalURL` property in your config) -1. Provide the OpenID Connect client's issuer, client ID, and client secret in the Sourcegraph site configuration shown below. +1. Provide the OpenID Connect client's issuer, client ID, and client secret in the Sourcegraph advanced configuration shown below. 1. (Optional) Require users to have a specific email domain name to authenticate (e.g., to limit users to only those from your organization). Example [`openidconnect` auth provider](/admin/config/site-config#openid-connect-including-google-workspace) configuration: @@ -456,7 +456,7 @@ See the [`openid` auth provider documentation](/admin/config/site-config#openid- **allowSignup** If true or not set, it allows new users to creating their Sourcegraph accounts via OpenID. -When `false`, sign-up won't be available and a site admin should create new users accounts. +When `false`, sign-up won't be available and an administrator should create new users accounts. ```json { @@ -475,7 +475,7 @@ Google's Workspace (formerly known as G Suite) supports OpenID Connect, which is - **Name:** Sourcegraph (or any other name your users will recognize) - **Authorized JavaScript origins:** (leave blank) - **Authorized redirect URIs:** `https://sourcegraph.example.com/.auth/callback` (replace `https://sourcegraph.example.com` with the value of the `externalURL` property in your config) -1. Use the **client ID** and **client secret** values in Sourcegraph site configuration (as shown in the example below). +1. Use the **client ID** and **client secret** values in Sourcegraph advanced configuration (as shown in the example below). 1. Set your Google Workspace domain in `requireEmailDomain` to prevent users outside your organization from signing in. Example [`openidconnect` auth provider](/admin/config/site-config#openid-connect-including-google-workspace) configuration for Google Workspace: @@ -500,7 +500,7 @@ Example [`openidconnect` auth provider](/admin/config/site-config#openid-connect You can wrap Sourcegraph in an authentication proxy that authenticates the user and passes the user's username or email (or both) to Sourcegraph via HTTP headers. The most popular such authentication proxy is [pusher/oauth2_proxy](https://github.com/pusher/oauth2_proxy). Another example is [Google Identity-Aware Proxy (IAP)](https://cloud.google.com/iap/). Both work well with Sourcegraph. -To use an authentication proxy to authenticate users to Sourcegraph, add the following lines to your site configuration: +To use an authentication proxy to authenticate users to Sourcegraph, add the following lines to your advanced configuration: ```json { @@ -523,7 +523,7 @@ For pusher/oauth2_proxy, use the `-pass-basic-auth false` option to prevent it f ### Username header prefixes -Some proxies add a prefix to the username header value. For example, Google IAP sets the `x-goog-authenticated-user-id` to a value like `accounts.google.com:alice` rather than just `alice`. If this is the case, use the `stripUsernameHeaderPrefix` field. If using Google IAP, for example, add the following lines to your site configuration: +Some proxies add a prefix to the username header value. For example, Google IAP sets the `x-goog-authenticated-user-id` to a value like `accounts.google.com:alice` rather than just `alice`. If this is the case, use the `stripUsernameHeaderPrefix` field. If using Google IAP, for example, add the following lines to your advanced configuration: ```json { @@ -544,7 +544,7 @@ In most cases, the link between a Sourcegraph account and an authentication prov Consequently, you can only sign in via an auth provider if your email on Sourcegraph matches the one configured in the auth provider. -Let's say the email field in your Sourcegraph account was kept blank when a site admin created the account for you, but the username matches your username on GitHub or GitLab. Will this work? If you try to sign in to SG with GitHub or GitLab, it won't work, and you will see an error informing you that a verified email is missing. +Let's say the email field in your Sourcegraph account was kept blank when an administrator created the account for you, but the username matches your username on GitHub or GitLab. Will this work? If you try to sign in to SG with GitHub or GitLab, it won't work, and you will see an error informing you that a verified email is missing. Exceptions to this rule are [HTTP Proxies](#http-authentication-proxies), where there's an option to make the link via username only. For [Bitbucket](/admin/config/authorization-and-authentication#bitbucket-server--bitbucket-data-center-authorization), we don't support OAuth. Still, the match between the chosen auth provider used with Bitbucket and a user's Bitbucket account happens via username. diff --git a/docs/admin/auth/login-form.mdx b/docs/admin/auth/login-form.mdx index a681ef35d..07c7d6ac9 100644 --- a/docs/admin/auth/login-form.mdx +++ b/docs/admin/auth/login-form.mdx @@ -20,7 +20,7 @@ of auth providers is hardcoded in the application. The default order can be overridden with an optional `order` parameter. It is an integer and items will be sorted in natural order (1, 2, 3, ...). -Example [site configuration](/admin/config/site-config): +Example [advanced configuration](/admin/config/site-config): ```json { @@ -55,10 +55,10 @@ By default, the login form shows up to 5 primary auth provider buttons on the pa with the `Other login methods` button. This default can be changed, e.g. in case there are 1 or 2 preferred methods for users to login with. -For example there might be a different auth provider setup for regular engineers and a different one for site admins. +For example there might be a different auth provider setup for regular engineers and a different one for administrators. It makes sense to only show the default one to engineers to reduce confusion of regular users. -There is a [site configuration](/admin/config/site-config) parameter `auth.primaryLoginProvidersCount`: +There is a [advanced configuration](/admin/config/site-config) parameter `auth.primaryLoginProvidersCount`: ```json { @@ -76,9 +76,9 @@ when the `Other login methods` button is clicked. By default Sourcegraph shows a button for each auth provider, such as `Continue with GitHub`. The text label for the button is created from 2 parts: `Continue with` prefix and `Github`. These can be controlled with `displayPrefix` and `displayName` -optional parameters of auth provider in [site configuration](/admin/config/site-config): +optional parameters of auth provider in [advanced configuration](/admin/config/site-config): -Example [site configuration](/admin/config/site-config): +Example [advanced configuration](/admin/config/site-config): ```json { @@ -111,7 +111,7 @@ but still sync permissions from code hosts. This can be done by setting `"noSign This will hide the code host auth providers from the login form, but will still allow users to connect their external accounts from their User Settings > Account Security page. Users will also be presented with a modal upon sign-in, asking them to connect these external accounts. -Example [site configuration](/admin/config/site-config): +Example [advanced configuration](/admin/config/site-config): ```json { @@ -139,7 +139,7 @@ Example [site configuration](/admin/config/site-config): > NOTE: Hiding an auth provider is mostly useful for development purposes and special cases. It is also possible to hide the auth provider from the login form completely. Auth providers have a `hidden` boolean property. -See the [site configuration](/admin/config/site-config) example below: +See the [advanced configuration](/admin/config/site-config) example below: ```json { diff --git a/docs/admin/auth/saml/azure-ad.mdx b/docs/admin/auth/saml/azure-ad.mdx index 58c67b6e5..f5d9b0ab2 100644 --- a/docs/admin/auth/saml/azure-ad.mdx +++ b/docs/admin/auth/saml/azure-ad.mdx @@ -19,9 +19,11 @@ - You can leave the other configuration values set to their defaults. 3. Record the value of the "App Federation Metadata Url". You'll need this in the next section. -## 2. Add the SAML auth provider to Sourcegraph site config + -[Add a SAML auth provider](/admin/auth/#add-a-saml-provider) with `identityProviderMetadataURL` set to the "App Federation Metadata Url" you recorded in the previous section. Here is an example of what your site configuration should look like: +## 2. Add the SAML auth provider to Sourcegraph advanced configuration + +[Add a SAML auth provider](/admin/auth/#add-a-saml-provider) with `identityProviderMetadataURL` set to the "App Federation Metadata Url" you recorded in the previous section. Here is an example of what your advanced configuration should look like: ```json { diff --git a/docs/admin/auth/saml/generic.mdx b/docs/admin/auth/saml/generic.mdx index 4486c1356..95ebf09ac 100644 --- a/docs/admin/auth/saml/generic.mdx +++ b/docs/admin/auth/saml/generic.mdx @@ -18,14 +18,16 @@ If you do not see your identity provider in the list above or otherwise have tro Ensure the following values are set for the application configuration in the identity provider. (Note: the exact names and labels may vary slightly for different identity providers) -- **Assertion Consumer Service URL, Recipient URL, Destination URL, Single sign-on URL:** `https://sourcegraph.example.com/.auth/saml/acs` (substituting the `externalURL` from your [site configuration](/admin/config/site-config)) -- **Service Provider (issuer, entity ID, audience URI, metadata URL):** `https://sourcegraph.example.com/.auth/saml/metadata` (substituting the `externalURL` from your [site configuration](/admin/config/site-config)). Some identity providers require you to input these metadata values manually, instead of fetching everything from one URL. In that case, navigate to `https://sourcegraph.example.com/.auth/saml/metadata` and transcribe the values in the XML to the identity provider configuration. +- **Assertion Consumer Service URL, Recipient URL, Destination URL, Single sign-on URL:** `https://sourcegraph.example.com/.auth/saml/acs` (substituting the `externalURL` from your [advanced configuration](/admin/config/site-config)) +- **Service Provider (issuer, entity ID, audience URI, metadata URL):** `https://sourcegraph.example.com/.auth/saml/metadata` (substituting the `externalURL` from your [advanced configuration](/admin/config/site-config)). Some identity providers require you to input these metadata values manually, instead of fetching everything from one URL. In that case, navigate to `https://sourcegraph.example.com/.auth/saml/metadata` and transcribe the values in the XML to the identity provider configuration. - **Attribute statements (claims):** Sourcegraph _requires_ that an attribute `email` be set with the value of the user's verified email address. This is used to uniquely identify users to Sourcegraph. Other attributes such as `login` and `displayName` are optional. - `email` (required): the user's email - `login` (optional): the user's username - `displayName` (optional): the full name of the user - **Name ID**: `email` -## 2. Add a SAML auth provider to Sourcegraph site configuration + + +## 2. Add a SAML auth provider to Sourcegraph advanced configuration [Add a SAML auth provider](/admin/auth/saml/#add-a-saml-provider). diff --git a/docs/admin/auth/saml/index.mdx b/docs/admin/auth/saml/index.mdx index cad9aebf3..89af44cd7 100644 --- a/docs/admin/auth/saml/index.mdx +++ b/docs/admin/auth/saml/index.mdx @@ -22,7 +22,7 @@ For advanced SAML configuration options, see the [`saml` auth provider documenta ## Add a SAML provider -1. In Sourcegraph [site config](/admin/config/site-config), ensure `externalURL` is set to a value consistent with the URL you used in the previous section in the identity provider configuration. +1. In Sourcegraph [advanced configuration](/admin/config/site-config), ensure `externalURL` is set to a value consistent with the URL you used in the previous section in the identity provider configuration. > NOTE: Make sure to use the exact same scheme (`http` or `https`), and there should be no trailing slash. @@ -30,7 +30,7 @@ For advanced SAML configuration options, see the [`saml` auth provider documenta > WARNING: There can only be at most 1 element of type `saml` in `auth.providers`. Otherwise behavior is undefined. If you have another SAML auth provider configured, remove it from `auth.providers` before proceeding. -Here are some examples of what your site config might look like: +Here are some examples of what your advanced configuration might look like: - Example 1: @@ -102,7 +102,7 @@ If not set, it will default to `true`. } ``` -> NOTE: If Sourcegraph is running on a free license all users will be created as site admins. Learn more about license settings on our [pricing page](https://about.sourcegraph.com/pricing). +> NOTE: If Sourcegraph is running on a free license all users will be created as administrators. Learn more about license settings on our [pricing page](https://about.sourcegraph.com/pricing). **allowGroups** @@ -196,7 +196,7 @@ The above example does not contain any sensitive information. In a real network There are a variety of ways to decompress and decrypt XML. For an easy to use tools we recommend [samltool.com](https://www.samltool.com/), which provides a user friendly UI to accomplish these tasks. -If you're not sure why your SAML isn't working and you've collected the network request and response from your login attempts, please feel free to reach out to our support team at [support@sourcegraph.com](mailto:support@sourcegraph.com), **please redact any secret keys that may be present in your site configuration or SAML assertions before sharing with us at Sourcegraph.** +If you're not sure why your SAML isn't working and you've collected the network request and response from your login attempts, please feel free to reach out to our support team at [support@sourcegraph.com](mailto:support@sourcegraph.com), **please redact any secret keys that may be present in your advanced configuration or SAML assertions before sharing with us at Sourcegraph.** ## FAQ diff --git a/docs/admin/auth/saml/jump-cloud.mdx b/docs/admin/auth/saml/jump-cloud.mdx index dcc3bc84d..66c7c4ddc 100644 --- a/docs/admin/auth/saml/jump-cloud.mdx +++ b/docs/admin/auth/saml/jump-cloud.mdx @@ -1,6 +1,6 @@ # Configuring SAML with JumpCloud -> NOTE: Please substitute `https://sourcegraph.example.com` with the actual value of `externalURL` in your [site configuration](/admin/config/site-config)). +> NOTE: Please substitute `https://sourcegraph.example.com` with the actual value of `externalURL` in your [advanced configuration](/admin/config/site-config)). ## 1. Configure SAML 2.0 application on JumpCloud @@ -25,7 +25,7 @@ Once the application is created, look for a tiny link called **export metadata** ## 2. Configure SAML authentication provider in Sourcegraph -[Add a SAML auth provider](/admin/auth/saml/#add-a-saml-provider) with `configID` set to the **SP Entity ID**, and `identityProviderMetadata` set to the content of the metadata you saved in the previous section. Here is an example of what your site configuration should look like: +[Add a SAML auth provider](/admin/auth/saml/#add-a-saml-provider) with `configID` set to the **SP Entity ID**, and `identityProviderMetadata` set to the content of the metadata you saved in the previous section. Here is an example of what your advanced configuration should look like: ```json { diff --git a/docs/admin/auth/saml/microsoft-adfs.mdx b/docs/admin/auth/saml/microsoft-adfs.mdx index da716e3e2..1cf58a34e 100644 --- a/docs/admin/auth/saml/microsoft-adfs.mdx +++ b/docs/admin/auth/saml/microsoft-adfs.mdx @@ -13,7 +13,7 @@ These instructions guide you through configuring Sourcegraph as a relying party - Active Directory instance where all users have email and username attributes. - An instance of ADFS running on Windows Server, joined to your Active Directory domain. - Sourcegraph should be [configured to use HTTPS](/self-hosted/http-https-configuration#nginx-sslhttps-configuration). -- Ensure that `externalURL` in [site config](/admin/config/site-config) meets the following +- Ensure that `externalURL` in [advanced configuration](/admin/config/site-config) meets the following criteria: - It is the URL used by end users (no trailing slash). - It is HTTPS. @@ -81,7 +81,9 @@ Click **Add Rule...** and proceed through the "Add Transform Claim Rule Wizard" Click **OK** to apply the new claim rules and close the window. -## 2. Add the SAML auth provider to Sourcegraph site config + + +## 2. Add the SAML auth provider to Sourcegraph advanced configuration [Add a SAML auth provider](/admin/auth/saml/#add-a-saml-provider) that points to your ADFS server's SAML metadata URL. This typically contains the path `/federationmetadata/2007-06/federationmetadata.xml`. Example: diff --git a/docs/admin/auth/saml/okta.mdx b/docs/admin/auth/saml/okta.mdx index 7800b6f08..2c0f74728 100644 --- a/docs/admin/auth/saml/okta.mdx +++ b/docs/admin/auth/saml/okta.mdx @@ -34,9 +34,11 @@ https://example.okta.com/app//sso/saml/metadata ``` -## 2. Add the SAML auth provider to Sourcegraph site config + -[Add a SAML auth provider](/admin/auth/saml/#add-a-saml-provider) with `identityProviderMetadataURL` set to the URL you copied from the "View IdP Metadata" link in the previous section. Here is an example of what your site configuration should look like: +## 2. Add the SAML auth provider to Sourcegraph advanced configuration + +[Add a SAML auth provider](/admin/auth/saml/#add-a-saml-provider) with `identityProviderMetadataURL` set to the URL you copied from the "View IdP Metadata" link in the previous section. Here is an example of what your advanced configuration should look like: ```json { diff --git a/docs/admin/auth/saml/one-login.mdx b/docs/admin/auth/saml/one-login.mdx index 7f49136dd..5d956b19c 100644 --- a/docs/admin/auth/saml/one-login.mdx +++ b/docs/admin/auth/saml/one-login.mdx @@ -20,7 +20,9 @@ URL". It should look something like `https://example.onelogin.com/saml/metadata/123456` or `https://app.onelogin.com/saml/metadata/123456`. Record this for the next section. -## 2. Add the SAML auth provider to Sourcegraph site config + + +## 2. Add the SAML auth provider to Sourcegraph advanced configuration [Add a SAML auth provider](/admin/auth/saml/#add-a-saml-provider) with `identityProviderMetadataURL` set to the Issuer URL recorded from the previous section. Here is an example: diff --git a/docs/admin/auth/troubleshooting.mdx b/docs/admin/auth/troubleshooting.mdx index 9671de15c..3b6a07f6f 100644 --- a/docs/admin/auth/troubleshooting.mdx +++ b/docs/admin/auth/troubleshooting.mdx @@ -53,7 +53,7 @@ An error has occurred The requested scope is invalid, unknown, or malformed. ``` -This could be related to the scopes granted on your `clientID` and `clientSecret` on the `auth.providers` section in your site configuration. +This could be related to the scopes granted on your `clientID` and `clientSecret` on the `auth.providers` section in your advanced configuration. For example, for the GitLab oAuth integration, check the [GitLab scopes](https://gitlab.com/-/profile/applications) granted to ensure that you have the following configured: @@ -101,9 +101,9 @@ If the cookie is not found in the **Request Headers**, then there is a problem. ### Things to collect for async analysis -- `"auth.providers"` portion of the Sourcegraph site configuration. Example: +- `"auth.providers"` portion of the Sourcegraph advanced configuration. Example: - !["auth.providers" site config](https://storage.googleapis.com/sourcegraph-assets/docs/images/auth/troubleshooting_sourcegraph_auth_providers.png) + !["auth.providers" advanced configuration](https://storage.googleapis.com/sourcegraph-assets/docs/images/auth/troubleshooting_sourcegraph_auth_providers.png) - A screenshot of the Sourcegraph OAuth application on the GitHub instance. Example: diff --git a/docs/admin/code-hosts/aws-codecommit.mdx b/docs/admin/code-hosts/aws-codecommit.mdx index 03bbd0e39..3ebd394cb 100644 --- a/docs/admin/code-hosts/aws-codecommit.mdx +++ b/docs/admin/code-hosts/aws-codecommit.mdx @@ -5,11 +5,11 @@ Available via the Web app. -Site admins can sync Git repositories hosted on [AWS CodeCommit](https://aws.amazon.com/codecommit/) with Sourcegraph so that users can search and navigate the repositories. +Administrators can sync Git repositories hosted on [AWS CodeCommit](https://aws.amazon.com/codecommit/) with Sourcegraph so that users can search and navigate the repositories. To connect AWS CodeCommit to Sourcegraph: -1. Go to **Site admin > Manage code hosts > Add repositories** +1. Go to **Administration > Manage code hosts > Add repositories** 1. Select **AWS CodeCommit repositories**. 1. Configure the connection to AWS CodeCommit using the action buttons above the text field, and additional fields can be added using `Cmd/Ctrl+Space` for auto-completion. See the [configuration documentation below](#configuration). 1. Press **Add repositories**. @@ -29,7 +29,7 @@ For detailed instructions on how to create the credentials in IAM, see: [Setup f ## Configuration -AWS CodeCommit connections support the following configuration options, which are specified in the JSON editor in the site admin "Manage code hosts" area. +AWS CodeCommit connections support the following configuration options, which are specified in the JSON editor in the Administration "Manage code hosts" area. {/*
[View page on our docs](/admin/code-hosts/aws-codecommit) to see rendered content.
*/} @@ -139,7 +139,7 @@ To add CodeCommit repositories in Docker Container: 1. Read our [guide here](/self-hosted/deploy/docker-compose/#git-ssh-configuration) for Docker Compose deployments 1. Read our [guide here](/self-hosted/deploy/kubernetes/configure#ssh-for-cloning) for Kubernetes deployments 1. Start (or restart) the container. -1. Connect Sourcegraph to AWS CodeCommit by going to **Sourcegraph > Site Admin > Manage code hosts > Generic Git host** and add the following: +1. Connect Sourcegraph to AWS CodeCommit by going to **Sourcegraph > Administration > Manage code hosts > Generic Git host** and add the following: ```json "url": "ssh://git-codecommit.us-west-1.amazonaws.com", //Please replace the 'us-east-1' region with yours diff --git a/docs/admin/code-hosts/azuredevops.mdx b/docs/admin/code-hosts/azuredevops.mdx index 98998cc1b..1519af0e3 100644 --- a/docs/admin/code-hosts/azuredevops.mdx +++ b/docs/admin/code-hosts/azuredevops.mdx @@ -5,7 +5,7 @@ Available via the Web app. -Site admins can sync Git repositories hosted on [Azure DevOps](https://dev.azure.com) with Sourcegraph so that users can search and navigate the repositories. +Administrators can sync Git repositories hosted on [Azure DevOps](https://dev.azure.com) with Sourcegraph so that users can search and navigate the repositories. To connect Azure DevOps to Sourcegraph, create a personal access token from your user settings page by following the below steps: @@ -17,7 +17,7 @@ To connect Azure DevOps to Sourcegraph, create a personal access token from your ![Click on New Token](https://storage.googleapis.com/sourcegraph-assets/docs/images/admin/config/azure-devops-personal-access-token-step-2.png) -3. Under the `Organization` menu, select `All accessible organizations` to allow access to all organizations. This is required to be able to perform connection checks from the code host page and to sync repositories from multiple organizations. Alternatively, site admins may also create a unique user that has access to only the selective organizations that they would like to sync with Sourcegraph. However the token being created **must** have access to `All accessible organizations` as shown below. +3. Under the `Organization` menu, select `All accessible organizations` to allow access to all organizations. This is required to be able to perform connection checks from the code host page and to sync repositories from multiple organizations. Alternatively, administrators may also create a unique user that has access to only the selective organizations that they would like to sync with Sourcegraph. However the token being created **must** have access to `All accessible organizations` as shown below. ![Select All accessible organizations](https://storage.googleapis.com/sourcegraph-assets/docs/images/admin/config/azure-devops-personal-access-token-step-3.png) @@ -29,7 +29,7 @@ To connect Azure DevOps to Sourcegraph, create a personal access token from your Next, configure the code host connection by following the next steps: -1. Go to **Site admin > Manage code hosts > Add repositories**. +1. Go to **Administration > Manage code hosts > Add repositories**. 1. Select **Azure DevOps**. 1. Provide a [configuration](#configuration) for the Azure DevOps code host connection. Here is an example configuration: @@ -61,7 +61,7 @@ Sourcegraph clones repositories from Azure DevOps via HTTP(S), using the [`usern ## Configuration -Azure DevOps connections support the following configuration options, which are specified in the JSON editor in the site admin "Manage code hosts" area. +Azure DevOps connections support the following configuration options, which are specified in the JSON editor in the Administration "Manage code hosts" area. {/*
[View page on our docs](/admin/code-hosts/azuredevops) to see rendered content.
*/} diff --git a/docs/admin/code-hosts/bitbucket-cloud.mdx b/docs/admin/code-hosts/bitbucket-cloud.mdx index 2ae83b7c8..f5d5c66c0 100644 --- a/docs/admin/code-hosts/bitbucket-cloud.mdx +++ b/docs/admin/code-hosts/bitbucket-cloud.mdx @@ -5,11 +5,11 @@ Available via the Web app. -Site admins can sync Git repositories hosted on [Bitbucket Cloud](https://bitbucket.org) with Sourcegraph so that users can search and navigate the repositories. +Administrators can sync Git repositories hosted on [Bitbucket Cloud](https://bitbucket.org) with Sourcegraph so that users can search and navigate the repositories. To connect Bitbucket Cloud to Sourcegraph: -1. Go to **Site admin > Code host connections > Add connection**. +1. Go to **Administration > Code host connections > Add connection**. 2. Select **Bitbucket.org**. 3. Configure the connection to Bitbucket Cloud using the action buttons above the text field. Additional fields can be added using Cmd/Ctrl+Space for auto-completion. See the [configuration documentation below](#configuration). 4. Press **Add connection**. @@ -108,7 +108,7 @@ Then, add or edit a Bitbucket Cloud connection as described above and include th ## Configuration -Bitbucket Cloud connections support the following configuration options, which are specified in the JSON editor in the site admin "Manage code hosts" area. +Bitbucket Cloud connections support the following configuration options, which are specified in the JSON editor in the Administration "Manage code hosts" area. {/*
[View page on our docs](/admin/code-hosts/bitbucket-cloud) to see rendered content.
*/} diff --git a/docs/admin/code-hosts/bitbucket-server.mdx b/docs/admin/code-hosts/bitbucket-server.mdx index 971b88cb3..9b300f3c7 100644 --- a/docs/admin/code-hosts/bitbucket-server.mdx +++ b/docs/admin/code-hosts/bitbucket-server.mdx @@ -5,11 +5,11 @@ Available via the Web app. -Site admins can sync Git repositories hosted on [Bitbucket Server](https://www.atlassian.com/software/bitbucket/server) or [Bitbucket Data Center](https://www.atlassian.com/enterprise/data-center/bitbucket) with Sourcegraph so that users can search and navigate their repositories. +Administrators can sync Git repositories hosted on [Bitbucket Server](https://www.atlassian.com/software/bitbucket/server) or [Bitbucket Data Center](https://www.atlassian.com/enterprise/data-center/bitbucket) with Sourcegraph so that users can search and navigate their repositories. To connect Bitbucket Server / Bitbucket Data Center to Sourcegraph: -1. Go to **Site admin > Manage code hosts > Add repositories** +1. Go to **Administration > Manage code hosts > Add repositories** 1. Select **Bitbucket Server / Bitbucket Data Center**. 1. Configure the connection to Bitbucket Server / Bitbucket Data Center using the action buttons above the text field, and additional fields can be added using Cmd/Ctrl+Space for auto-completion. See the [configuration documentation below](#configuration). 1. Press **Add repositories**. @@ -56,7 +56,7 @@ Enforcing Bitbucket Server / Bitbucket Data Center permissions can be configured ### Prerequisites 1. You have the exact same user accounts, **with matching usernames**, in Sourcegraph and Bitbucket Server / Bitbucket Data Center. This can be accomplished by configuring an [external authentication provider](/admin/auth/) that mirrors user accounts from a central directory like LDAP or Active Directory. The same should be done on Bitbucket Server / Bitbucket Data Center with [external user directories](https://confluence.atlassian.com/bitbucketserver/external-user-directories-776640394.html). -1. Ensure you have set `auth.enableUsernameChanges` to **`false`** in the [site config](/admin/config/site-config) to prevent users from changing their usernames and **escalating their privileges**. +1. Ensure you have set `auth.enableUsernameChanges` to **`false`** in the [advanced configuration](/admin/config/site-config) to prevent users from changing their usernames and **escalating their privileges**. ### Setup @@ -168,7 +168,7 @@ With the [Sourcegraph Bitbucket Server plugin](/integration/bitbucket-server#sou 1. Connect Bitbucket Server / Bitbucket Data Center to Sourcegraph (_see instructions above_). 1. Follow the [instructions to set up repository permissions](#repository-permissions) with Bitbucket Server / Bitbucket Data Center. 1. Install the [Sourcegraph Bitbucket Server plugin](/integration/bitbucket-server#sourcegraph-bitbucket-server-plugin) on your Bitbucket Server / Bitbucket Data Center instance. -1. In Sourcegraph, go to **Site admin > Manage code hosts** and edit the Bitbucket Server / Bitbucket Data Center configuration. +1. In Sourcegraph, go to **Administration > Manage code hosts** and edit the Bitbucket Server / Bitbucket Data Center configuration. 1. Add the `"plugin.permissions"` property: ```json @@ -194,7 +194,7 @@ See [Internal rate limits](/admin/code-hosts/rate-limits#internal-rate-limits). ## Configuration -Bitbucket Server / Bitbucket Data Center connections support the following configuration options, which are specified in the JSON editor in the site admin "Manage code hosts" area. +Bitbucket Server / Bitbucket Data Center connections support the following configuration options, which are specified in the JSON editor in the Administration "Manage code hosts" area. {/*
[View page on our docs](/admin/code-hosts/bitbucket-server) to see rendered content.
*/} diff --git a/docs/admin/code-hosts/gerrit.mdx b/docs/admin/code-hosts/gerrit.mdx index f1ba8fbe0..69242d8ea 100644 --- a/docs/admin/code-hosts/gerrit.mdx +++ b/docs/admin/code-hosts/gerrit.mdx @@ -21,8 +21,8 @@ A Gerrit instance can be connected to Sourcegraph as follows: ## Configure Gerrit as a code host connection -1. In the **Site Admin** settings area, select **Manage code hosts** from the options on the left and select the **Add code host** option. - ![The Manage code hosts section in the Site Admin settings area.](https://storage.googleapis.com/sourcegraph-assets/docs/images/administration/config/external-services/gerrit/gerrit-manage-code-hosts.png) +1. In the **Administration** settings area, select **Manage code hosts** from the options on the left and select the **Add code host** option. + ![The Manage code hosts section in the Administration settings area.](https://storage.googleapis.com/sourcegraph-assets/docs/images/administration/config/external-services/gerrit/gerrit-manage-code-hosts.png) 2. On the following screen, select **Gerrit** as the code host of choice. ![Gerrit as a code host option in the list](https://storage.googleapis.com/sourcegraph-assets/docs/images/administration/config/external-services/gerrit/gerrit-select.png) 3. Next you will have to provide a [configuration](#configuration) for the Gerrit code host connection. Here is an example configuration: @@ -74,7 +74,7 @@ To clone using SSH, provide `"gitSSHCredential"` in the configuration: If the `"authorization": {}` option has been set on a Gerrit code host connection, a Gerrit authentication provider will be required so that authorized users are able to search for and browse the code mirrored by that code host connection. -1. In the **Site Admin** settings area, select [**Site configuration**](/admin/config/site-config) from the options on the left. +1. In the **Administration** settings area, select [**Advanced configuration**](/admin/config/site-config) from the options on the left. 2. Add a Gerrit configuration to the list of `"auth.providers"`. ![Add a Gerrit configuration to the list of configured authentication providers](https://storage.googleapis.com/sourcegraph-assets/docs/images/administration/config/external-services/gerrit/gerrit-auth.png) 3. Here is an example configuration: @@ -105,7 +105,7 @@ As a user: ## Configuration -Gerrit connections support the following configuration options, which are specified in the JSON editor in the site admin "Manage code hosts" area. +Gerrit connections support the following configuration options, which are specified in the JSON editor in the Administration "Manage code hosts" area. {/*
[View page on our docs](/admin/code-hosts/gerrit) to see rendered content.
*/} diff --git a/docs/admin/code-hosts/github.mdx b/docs/admin/code-hosts/github.mdx index d391cb160..c62b3676d 100644 --- a/docs/admin/code-hosts/github.mdx +++ b/docs/admin/code-hosts/github.mdx @@ -5,7 +5,7 @@ plans. -Site admins can sync Git repositories hosted on [GitHub.com](https://github.com) and [GitHub Enterprise](https://enterprise.github.com) with Sourcegraph so that users can search and navigate the repositories. +Administrators can sync Git repositories hosted on [GitHub.com](https://github.com) and [GitHub Enterprise](https://enterprise.github.com) with Sourcegraph so that users can search and navigate the repositories. There are 2 ways to connect with GitHub: @@ -34,7 +34,7 @@ There are two ways to connect a GitHub App: To create a GitHub App and connect it to Sourcegraph: -1. Go to **Site admin > Repositories > Github Apps** on Sourcegraph. +1. Go to **Administration > Repositories > Github Apps** on Sourcegraph. ![The GitHub Apps page on Sourcegraph](https://sourcegraphstatic.com/docs/images/administration/config/github-apps/github-apps-list-dark.png) @@ -69,7 +69,7 @@ To create a GitHub App and connect it to Sourcegraph: ![The GitHub App details page on Sourcegraph](https://sourcegraphstatic.com/docs/images/administration/config/github-apps/github-app-post-create-dark.png) -7. Sourcegraph needs to map Sourcegraph users to GitHub users. Click **Reveal secret** to get the JSON configuration for the auth provider and copy/paste it into the `"auth.providers"` section of your site configuration. +7. Sourcegraph needs to map Sourcegraph users to GitHub users. Click **Reveal secret** to get the JSON configuration for the auth provider and copy/paste it into the `"auth.providers"` section of your advanced configuration. 8. Click **Add connection** under your new installation to create a code host connection to GitHub with this App installation. By default, it will sync all repositories the App can access within the namespace where it was installed. Repository permission enforcement will also be turned on by default. You can now [select repositories to sync](#selecting-repositories-to-sync) or see more configuration options in the [configuration section](#configuration). @@ -98,7 +98,7 @@ Once public, App can be installed in additional namespaces either from Sourcegra ##### Installing from Sourcegraph -1. Go to **Site admin > Repositories > Github Apps** and click **Edit** on the App you want to install in another namespace. You'll be taken to the App details page. +1. Go to **Administration > Repositories > Github Apps** and click **Edit** on the App you want to install in another namespace. You'll be taken to the App details page. ![The GitHub App details page on Sourcegraph](https://sourcegraphstatic.com/docs/images/administration/config/github-apps/github-app-post-create-dark.png) @@ -119,7 +119,7 @@ Once public, App can be installed in additional namespaces either from Sourcegra 1. Go to the GitHub App page. You can get here easily from Sourcegraph by clicking **View in GitHub** for the App you want to install in another namespace. 2. Click **Configure**, or go to **App settings > Install App**, and select the organization or user account you want to install the App on. 3. As before, you will be asked to review the App permissions and select which repositories the App can access before installing it in a namespace. Once you click **Install** and the setup completes, you will be redirected back to Sourcegraph. -4. GitHub App installations will be automatically synced in the background. Return to **Site admin > Repositories > Github Apps** and click **Edit** on the App you added the new installation for. You'll be taken to the App details page. Once synced, you will see the new installation listed. +4. GitHub App installations will be automatically synced in the background. Return to **Administration > Repositories > Github Apps** and click **Edit** on the App you added the new installation for. You'll be taken to the App details page. Once synced, you will see the new installation listed. ![The GitHub App details page on Sourcegraph, scrolled to show a second new installation](https://sourcegraphstatic.com/docs/images/administration/config/github-apps/github-app-post-multi-install-dark.png) @@ -134,7 +134,7 @@ If you have an existing GitHub App (such as a GitHub Enterprise App), you can co To add an existing GitHub App: -1. Go to **Site admin > Repositories > Github Apps** on Sourcegraph. +1. Go to **Administration > Repositories > Github Apps** on Sourcegraph. 2. Click **Add an existing GitHub App**. 3. Enter the following details of your existing GitHub App: - **GitHub URL**: The URL of your GitHub instance (e.g., `https://github.com` or `https://github.example.com`) @@ -177,7 +177,7 @@ You can uninstall a GitHub App from a namespace or remove it altogether at any t To remove an installation in a single namespace, click **View in GitHub** for the installation you want to remove. If you are able to administer Apps in this namespace, you will see **Uninstall "[APP NAME]"** in the "Danger zone" at the bottom of the page. Click **Uninstall** to remove the App from this namespace. Sourcegraph will periodically sync installations in the background. It may temporarily throw errors related to the missing installation until the sync completes. You can check the GitHub App details page to confirm the installation has been removed. -To remove an App entirely, go to **Site admin > Repositories > Github Apps** and click **Remove** for the App you want to remove. You will be prompted to confirm you want to remove the App from Sourcegraph. Once removed from the Sourcegraph side, Sourcegraph will no longer communicate with your GitHub instance via the App unless explicitly reconnected. However, the App will still exist on GitHub unless manually deleted there, as well. +To remove an App entirely, go to **Administration > Repositories > Github Apps** and click **Remove** for the App you want to remove. You will be prompted to confirm you want to remove the App from Sourcegraph. Once removed from the Sourcegraph side, Sourcegraph will no longer communicate with your GitHub instance via the App unless explicitly reconnected. However, the App will still exist on GitHub unless manually deleted there, as well. ### GitHub App token use @@ -194,7 +194,7 @@ These are OAuth tokens that Sourcegraph receives when a user signs into Sourcegr ### Custom Certificates If you are using a self-signed certificate for your GitHub Enterprise instance, configure `tls.external` -in the **Site configuration** with your certificate(s). +in the **Advanced configuration** with your certificate(s). ```json { @@ -208,7 +208,7 @@ in the **Site configuration** with your certificate(s). To connect GitHub to Sourcegraph with an access token: -1. Go to **Site admin > Manage code hosts** +1. Go to **Administration > Manage code hosts** 2. Select **GitHub**. 3. Configure the connection to GitHub using the action buttons above the text field, and additional fields can be added using Cmd/Ctrl+Space for auto-completion. See the [configuration documentation below](#configuration). 4. Press **Add repositories**. @@ -397,7 +397,7 @@ This caching behaviour can be enabled via the `authorization.groupsCacheTTL` fie } ``` -In the corresponding [authorization provider](/admin/auth/#github) in [site configuration](/admin/config/site-config), the `allowGroupsPermissionsSync` field must be set as well for the correct auth scopes to be requested from users: +In the corresponding [authorization provider](/admin/auth/#github) in [advanced configuration](/admin/config/site-config), the `allowGroupsPermissionsSync` field must be set as well for the correct auth scopes to be requested from users: ```json { @@ -448,7 +448,7 @@ Please consult [this page](/admin/webhooks/incoming) in order to configure webho ## Configuration -GitHub connections support the following configuration options, which are specified in the JSON editor in the site admin "Manage code hosts" area. +GitHub connections support the following configuration options, which are specified in the JSON editor in the Administration "Manage code hosts" area. {/*
[View page on our docs](/admin/code-hosts/github) to see rendered content.
*/} diff --git a/docs/admin/code-hosts/gitlab.mdx b/docs/admin/code-hosts/gitlab.mdx index b9cce1c50..9f6698e2e 100644 --- a/docs/admin/code-hosts/gitlab.mdx +++ b/docs/admin/code-hosts/gitlab.mdx @@ -5,11 +5,11 @@ [Enterprise](/pricing/plans/enterprise) plans. -Site admins can sync Git repositories hosted on [GitLab](https://gitlab.com) (GitLab.com and GitLab CE/EE) with Sourcegraph so that users can search and navigate the repositories. +Administrators can sync Git repositories hosted on [GitLab](https://gitlab.com) (GitLab.com and GitLab CE/EE) with Sourcegraph so that users can search and navigate the repositories. To connect GitLab to Sourcegraph: -1. Go to **Site admin > Manage code hosts > Add code host** +1. Go to **Administration > Manage code hosts > Add code host** 2. Select **GitLab** (for GitLab.com) or **GitLab Self-Managed**. 3. Set **url** to the URL of your GitLab instance, such as https://gitlab.example.com or https://gitlab.com (for GitLab.com). 4. Create a GitLab access token using these [instructions](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#creating-a-personal-access-token) with the `read_api` and `read_repository` scopes, and set it to be the value of the token. @@ -306,7 +306,7 @@ See [Internal rate limits](/admin/code-hosts/rate-limits#internal-rate-limits). To provide out-of-the-box code navigation features to your users on GitLab, you will need to [configure your GitLab instance](https://docs.gitlab.com/ee/integration/sourcegraph.html). If you are using an HTTPS connection to GitLab, you will need to [configure HTTPS](/self-hosted/http-https-configuration) for your Sourcegraph instance. -The Sourcegraph instance's site admin must [update the `corsOrigin` site config property](/admin/config/site-config) to allow the GitLab instance to communicate with the Sourcegraph instance. For example: +The Sourcegraph instance's administrator must [update the `corsOrigin` advanced configuration property](/admin/config/site-config) to allow the GitLab instance to communicate with the Sourcegraph instance. For example: ```json { diff --git a/docs/admin/code-hosts/gitolite.mdx b/docs/admin/code-hosts/gitolite.mdx index b18acd4f1..8c089649e 100644 --- a/docs/admin/code-hosts/gitolite.mdx +++ b/docs/admin/code-hosts/gitolite.mdx @@ -7,12 +7,12 @@ > NOTE: While it is possible to connect Gitolite repositories to Sourcegraph, we currently do not recommend it. If you have specific questions, please discuss with your account team. -Site admins can link and sync Git repositories on [Gitolite](https://gitolite.com) with Sourcegraph so that users can search and navigate the repositories. +Administrators can link and sync Git repositories on [Gitolite](https://gitolite.com) with Sourcegraph so that users can search and navigate the repositories. To connect Gitolite to Sourcegraph: 1. Set up [git SSH authentication](/admin/repo/auth) for your gitolite server. -1. Go to **Site admin > Manage code hosts > Add repositories** +1. Go to **Administration > Manage code hosts > Add repositories** 1. Select **Gitolite**. 1. Configure the connection to Gitolite using the action buttons above the text field, and additional fields can be added using `Cmd/Ctrl+Space` for auto-completion. See the [configuration documentation below](#configuration). 1. Press **Add repositories**. diff --git a/docs/admin/code-hosts/index.mdx b/docs/admin/code-hosts/index.mdx index 11edd1950..a5f98920f 100644 --- a/docs/admin/code-hosts/index.mdx +++ b/docs/admin/code-hosts/index.mdx @@ -43,7 +43,7 @@ We recognize there are other code hosts including CVS, SVN, and many more. Today ## Configure a code host connection -**Site admins** can configure Sourcegraph to sync code from the following code hosts: +**Administrators** can configure Sourcegraph to sync code from the following code hosts: - [GitHub](/admin/code-hosts/github) - [GitLab](/admin/code-hosts/gitlab) @@ -63,7 +63,7 @@ For information on code host-related rate limits, see [rate limits](/admin/code- ## Temporarily disabling requests to code hosts -It may be the case that you'd like to temporarily reduce or pause the `git` and API requests Sourcegraph sends to a code host. Adding the following to your site configuration will stop Sourcegraph's periodic background traffic and rate-limit git operations to zero: +It may be the case that you'd like to temporarily reduce or pause the `git` and API requests Sourcegraph sends to a code host. Adding the following to your advanced configuration will stop Sourcegraph's periodic background traffic and rate-limit git operations to zero: > WARNING: applying these settings will also disable permissions syncs, batch changes, discovery of new repos, and updates to currently synched repos. Syncing with codehosts is a core functionality of Sourcegraph and many other features may also be affected. @@ -83,7 +83,7 @@ What each setting does: ## Using Self-signed TLS Certificates -To use Sourcegraph with self-signed TLS Certificates, update the site configuration to add the certificate and skip verification of the certificate chain: +To use Sourcegraph with self-signed TLS Certificates, update the advanced configuration to add the certificate and skip verification of the certificate chain: ```json "tls.external": { @@ -96,7 +96,7 @@ To use Sourcegraph with self-signed TLS Certificates, update the site configurat ## Using mTLS (Mutual TLS) for Code Hosts -If your code host requires mutual TLS (mTLS) authentication, you can configure client certificates per host using the `mtlsConfigurations` field in your site configuration: +If your code host requires mutual TLS (mTLS) authentication, you can configure client certificates per host using the `mtlsConfigurations` field in your advanced configuration: ```json "tls.external": { diff --git a/docs/admin/code-hosts/non-git.mdx b/docs/admin/code-hosts/non-git.mdx index 9b7f8414b..af3418578 100644 --- a/docs/admin/code-hosts/non-git.mdx +++ b/docs/admin/code-hosts/non-git.mdx @@ -107,7 +107,7 @@ depending on whether you want to automatically sync and commit changes, or just **IMPORTANT:** If you are using a Linux host machine, replace `host.docker.internal` in the above with the IP address of your actual host machine because `host.docker.internal` [does not work on Linux](https://github.com/docker/for-linux/issues/264). You should use the network-accessible IP shown by `ifconfig` (rather than 127.0.0.1 or localhost). -Go to **Admin > Manage code hosts > Add repositories > Single Git repositories**. Input the above configuration. Your directories should now be syncing in Sourcegraph. +Go to **Administration > Manage code hosts > Add repositories > Single Git repositories**. Input the above configuration. Your directories should now be syncing in Sourcegraph. ### Next steps: advanced configuration diff --git a/docs/admin/code-hosts/other.mdx b/docs/admin/code-hosts/other.mdx index 1f3199117..a5a661a10 100644 --- a/docs/admin/code-hosts/other.mdx +++ b/docs/admin/code-hosts/other.mdx @@ -5,11 +5,11 @@ Available via the Web app. -Site admins can sync Git repositories on any Git repository host (by Git clone URL) with Sourcegraph so that users can search and navigate the repositories. Use this method only when your repository host is not named as a supported [code host](/admin/code-hosts/). +Administrators can sync Git repositories on any Git repository host (by Git clone URL) with Sourcegraph so that users can search and navigate the repositories. Use this method only when your repository host is not named as a supported [code host](/admin/code-hosts/). To connect generic Git host to Sourcegraph: -1. Go to **Site admin > Manage code hosts > Add repositories** +1. Go to **Administration > Manage code hosts > Add repositories** 1. Select **Generic Git host**. 1. Configure the connection to generic Git host the action buttons above the text field, and additional fields can be added using `Cmd/Ctrl+Space` for auto-completion. See the [configuration documentation below](#configuration). 1. Press **Add repositories**. diff --git a/docs/admin/code-hosts/phabricator.mdx b/docs/admin/code-hosts/phabricator.mdx index 11ea89205..844c7d54d 100644 --- a/docs/admin/code-hosts/phabricator.mdx +++ b/docs/admin/code-hosts/phabricator.mdx @@ -5,20 +5,20 @@ Available via the Web app. -Site admins can associate Git repositories on [Phabricator](https://phabricator.org) with Sourcegraph so that users can jump to the Phabricator repository from Sourcegraph and use the [Phabricator extension](#native-extension) and [browser extension](/integration/browser-extension) with Phabricator. +Administrators can associate Git repositories on [Phabricator](https://phabricator.org) with Sourcegraph so that users can jump to the Phabricator repository from Sourcegraph and use the [Phabricator extension](#native-extension) and [browser extension](/integration/browser-extension) with Phabricator. > ⚠️ NOTE: Sourcegraph support of Phabricator is limited ([learn more](/integration/phabricator)), and not expected to evolve due to the [announced](https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_operations/) cease of support for Phabricator. To connect Phabricator to Sourcegraph: -1. Go to **Site admin > Manage code hosts > Add repositories** +1. Go to **Administration > Manage code hosts > Add repositories** 1. Select **Phabricator**. 1. Configure the connection to Phabricator using the action buttons above the text field, and additional fields can be added using `Cmd/Ctrl+Space` for auto-completion. See the [configuration documentation below](#configuration). 1. Press **Add repositories**. ## Repository association -Sourcegraph can provide users with links to various Phabricator pages (for files, commits, branches, etc.) if you add Phabricator as a connection (in **Site admin > Manage code hosts**). +Sourcegraph can provide users with links to various Phabricator pages (for files, commits, branches, etc.) if you add Phabricator as a connection (in **Administration > Manage code hosts**). A Phabricator configuration consists of the following fields: @@ -58,7 +58,7 @@ For production usage, we recommend installing the Sourcegraph Phabricator extens See the [phabricator-extension](https://github.com/sourcegraph/phabricator-extension) repository for installation instructions and configuration settings. -The Sourcegraph instance's site admin must [update the `corsOrigin` site config property](/admin/config/site-config) to allow the Phabricator extension to communicate with the Sourcegraph instance. For example: +The Sourcegraph instance's administrator must [update the `corsOrigin` advanced configuration property](/admin/config/site-config) to allow the Phabricator extension to communicate with the Sourcegraph instance. For example: ```json { diff --git a/docs/admin/code-hosts/rate-limits.mdx b/docs/admin/code-hosts/rate-limits.mdx index 269e8765c..0abb55b8f 100644 --- a/docs/admin/code-hosts/rate-limits.mdx +++ b/docs/admin/code-hosts/rate-limits.mdx @@ -30,7 +30,7 @@ Sourcegraph monitors external rate limits for the following code hosts: Internal rate limits refer to self-imposed rate limits within Sourcegraph. While Sourcegraph adheres to external rate limits, sometimes more control is necessary, or a code host might not have rate limit monitoring available or configured. In these cases, internal rate limits can be configured. -A [global default internal rate limit](/admin/config/site-config#defaultRateLimit) can be configured in the [site configuration](/admin/config/site-config). This limit applies to all code host connections that don't have a specific rate limit configured. +A [global default internal rate limit](/admin/config/site-config#defaultRateLimit) can be configured in the [advanced configuration](/admin/config/site-config). This limit applies to all code host connections that don't have a specific rate limit configured. > NOTE: This is the default rate limit _per code host connection_. It is not the total rate limit of all the code host connections. @@ -55,7 +55,7 @@ Requests to the configured code host will be staggered as to not exceed `"reques - For Sourcegraph `<=3.38`, if rate limiting is configured more than once for the same code host instance, the most restrictive limit will be used. - For Sourcegraph >=3.39, rate limiting should be enabled and configured for each individual code host connection. -To see the status of configured internal rate limits, visit **Site admin > Instrumentation > worker > Rate Limiter State**. This page lists internal rate limits by code host, for example: +To see the status of configured internal rate limits, visit **Administration > Instrumentation > worker > Rate Limiter State**. This page lists internal rate limits by code host, for example: ```json { diff --git a/docs/admin/code-hosts/src-serve-git.mdx b/docs/admin/code-hosts/src-serve-git.mdx index f7017b6c8..eb81d4942 100644 --- a/docs/admin/code-hosts/src-serve-git.mdx +++ b/docs/admin/code-hosts/src-serve-git.mdx @@ -29,7 +29,7 @@ The most common use-case for `src serve-git` is to create git repos that do not 1. [Install Sourcegraph CLI](https://github.com/sourcegraph/src-cli#installation) (`src`). 1. Run `src serve-git` in a directory with git repositories. Ensure the address is reachable by Sourcegraph. -1. Go to **Site admin > Manage code hosts > Add repositories** +1. Go to **Administration > Manage code hosts > Add repositories** 1. Select **Sourcegraph CLI Serve-Git**. 1. Configure the URL field to the address for `src serve-git`. 1. Press **Add repositories**. diff --git a/docs/admin/config/authorization-and-authentication.mdx b/docs/admin/config/authorization-and-authentication.mdx index 8ba443d60..84eadcd01 100644 --- a/docs/admin/config/authorization-and-authentication.mdx +++ b/docs/admin/config/authorization-and-authentication.mdx @@ -9,7 +9,7 @@ We suggest configuring both when using Sourcegraph Enterprise. If you do not con ## Authentication -Sourcegraph supports username/password auth by default and SAML, OAuth, HTTP Proxy auth, and OpenID Connect if configured. Changing a username in Sourcegraph will allow the user to escalate permissions, so if you are syncing permissions, you will need to add the following to your site config at `https://sourcegraph.example.com/siteadmin/configuration` ([Learn more about viewing and editing your site configuration.](/admin/config/site-config#view-and-edit-site-configuration)) +Sourcegraph supports username/password auth by default and SAML, OAuth, HTTP Proxy auth, and OpenID Connect if configured. Changing a username in Sourcegraph will allow the user to escalate permissions, so if you are syncing permissions, you will need to add the following to your advanced configuration at `https://sourcegraph.example.com/siteadmin/configuration` ([Learn more about viewing and editing your advanced configuration.](/admin/config/site-config#view-and-edit-site-configuration)) ```json { @@ -19,7 +19,7 @@ Sourcegraph supports username/password auth by default and SAML, OAuth, HTTP Pro For users using any of the other authentication mechanisms, removing `builtin` as an authentication mechanism is best practice. -> NOTE: If Sourcegraph is running on a free license all users will be created as site admins. Learn more about license settings on our [pricing page](https://about.sourcegraph.com/pricing). +> NOTE: If Sourcegraph is running on a free license all users will be created as administrators. Learn more about license settings on our [pricing page](https://about.sourcegraph.com/pricing). ## Repository permissions in Sourcegraph @@ -35,7 +35,7 @@ We recommend that you start at the instructions for your code host, if listed, f ### Built-in username/password authentication -Built-in username/password authentication is Sourcegraph’s default authentication option. To enable it, add the following to your site config: +Built-in username/password authentication is Sourcegraph’s default authentication option. To enable it, add the following to your advanced configuration: ```json { @@ -100,7 +100,7 @@ We support authentication through OAuth for [Azure DevOps Services (dev.azure.co #### Configuring Sourcegraph auth.providers -With all the values acquired above, you can now add the following to the `auth.providers` key in the site config: +With all the values acquired above, you can now add the following to the `auth.providers` key in the advanced configuration: ```json { diff --git a/docs/admin/config/batch-changes.mdx b/docs/admin/config/batch-changes.mdx index e9ed8ecb6..276f6a964 100644 --- a/docs/admin/config/batch-changes.mdx +++ b/docs/admin/config/batch-changes.mdx @@ -1,6 +1,6 @@ -# Batch Changes site admin configuration reference +# Batch Changes administrator configuration reference -Batch Changes is generally configured through the same [site configuration](/admin/config/site-config) and [code host configuration](/admin/code-hosts/) as the rest of Sourcegraph. However, Batch Changes features may require specific configuration, and those are documented here. +Batch Changes is generally configured through the same [advanced configuration](/admin/config/site-config) and [code host configuration](/admin/code-hosts/) as the rest of Sourcegraph. However, Batch Changes features may require specific configuration, and those are documented here. ## Access control @@ -8,7 +8,7 @@ Batch Changes is [RBAC-enabled](/admin/access-control/). By default, all users h ### Enable organization members to administer -By default, only a batch change's author or a site admin can administer (apply, close, rename, etc.) a batch change. However, admins can use [organizations](/admin/organizations) to facilitate closer collaboration and shared administrative control over batch changes by enabling the `orgs.allMembersBatchChangesAdmin` setting for an organization. When enabled, members of the organization will be able to administer all batch changes created in that organization's namespace. Batch changes created in other namespaces (user or organization) will still be restricted to the author and site admins. +By default, only a batch change's author or an administrator can administer (apply, close, rename, etc.) a batch change. However, admins can use [organizations](/admin/organizations) to facilitate closer collaboration and shared administrative control over batch changes by enabling the `orgs.allMembersBatchChangesAdmin` setting for an organization. When enabled, members of the organization will be able to administer all batch changes created in that organization's namespace. Batch changes created in other namespaces (user or organization) will still be restricted to the author and administrators. ## Rollout windows @@ -16,7 +16,7 @@ By default, Sourcegraph attempts to reconcile (create, update, or close) changes Configuring rollout windows allows changesets to be reconciled at a slower or faster rate based on the time of day and/or the day of the week. These windows are applied to changesets across all code hosts, but they only affect the rate at which changesets are created/published, updated, or closed, as well as some other internal operations like importing and detaching. Bulk operations to publish changesets also respect the rollout window; however, bulk commenting, merging, and closing will happen all at once. -Rollout windows are configured through the `batchChanges.rolloutWindows` [site configuration option](/admin/config/site-config). If specified, this option contains an array of rollout window objects that are used to schedule changesets. The format of these objects [is given below](#rollout-window-object). +Rollout windows are configured through the `batchChanges.rolloutWindows` [advanced configuration option](/admin/config/site-config). If specified, this option contains an array of rollout window objects that are used to schedule changesets. The format of these objects [is given below](#rollout-window-object). ### Behavior @@ -133,13 +133,13 @@ Sourcegraph can track incoming webhooks from code hosts to more easily debug iss ## Forks -Sourcegraph can be configured to push branches created by Batch Changes to a fork of the repository, rather than the repository itself, for example if users of your code host typically do not have push access to the original repository. You can enable pushing to forks globally with the `batchChanges.enforceForks` site configuration option. Users can also indicate they do or do not want to push to forks for an individual batch change by specifying the property `changesetTemplate.fork` in their batch spec. If the batch spec property is present, it will override the site configuration option. See the [batch spec YAML reference](/batch-changes/batch-spec-yaml-reference#changesettemplatefork) for more information. +Sourcegraph can be configured to push branches created by Batch Changes to a fork of the repository, rather than the repository itself, for example if users of your code host typically do not have push access to the original repository. You can enable pushing to forks globally with the `batchChanges.enforceForks` advanced configuration option. Users can also indicate they do or do not want to push to forks for an individual batch change by specifying the property `changesetTemplate.fork` in their batch spec. If the batch spec property is present, it will override the advanced configuration option. See the [batch spec YAML reference](/batch-changes/batch-spec-yaml-reference#changesettemplatefork) for more information. The fork will be created in the namespace of the user publishing the changeset, or the namespace of the service account if [global service account](/batch-changes/configuring-credentials#global-service-account-tokens) is in use. The name of the fork Sourcegraph creates will be prefixed with the name of the original repo's namespace in order to prevent potential repo name collisions. For example, a batch spec targeting `github.com/my-org/project` would create or use any existing fork by the name `github.com/user/my-org-project`. ### Examples -To enable forks, update the site configuration to include: +To enable forks, update the advanced configuration to include: ```json { @@ -154,7 +154,7 @@ By default, classic and agentic Batch Changes identify the Sourcegraph batch cha - A link to the originating batch change appended to the pull request or merge request description. - A `Sourcegraph-Batch-Change` trailer in the commit message. -If description updates cause unwanted code host notifications, set `batchChanges.attributionMode` to `trailerOnly` in site configuration: +If description updates cause unwanted code host notifications, set `batchChanges.attributionMode` to `trailerOnly` in advanced configuration: ```json { @@ -173,13 +173,13 @@ The commit trailer always contains a link to the classic batch change or agent c ## Automatically delete branches on merge/close -Sourcegraph can be configured to automatically delete branches created for Batch Changes changesets when changesets are merged or closed by enabling the `batchChanges.autoDeleteBranch` site configuration option. +Sourcegraph can be configured to automatically delete branches created for Batch Changes changesets when changesets are merged or closed by enabling the `batchChanges.autoDeleteBranch` advanced configuration option. When enabled, Batch Changes will override any setting on the repository on the code host itself and attempt to remove the source branch of the changeset when the changeset is merged or closed. This is useful for keeping repositories clean of stale branches. Not every code host supports this in the same way; some code host APIs expose a property on the changeset which can be toggled to enable this behavior, while others require a separate API call to delete the branch after the changeset is merged/closed. -For those that support a changeset property, Batch Changes will automatically set the property to match the site config setting. The property will be updated whenever the changeset is updated, so that the settings stay in sync. Using a changeset property has the added benefit that the branch will be deleted even if the changeset is merged/closed on the code host itself, rather than through Sourcegraph. +For those that support a changeset property, Batch Changes will automatically set the property to match the advanced configuration setting. The property will be updated whenever the changeset is updated, so that the settings stay in sync. Using a changeset property has the added benefit that the branch will be deleted even if the changeset is merged/closed on the code host itself, rather than through Sourcegraph. For those that require a separate API call, Batch Changes will only be able to delete the branch if the changeset is merged/closed _using Sourcegraph_. If the changeset is merged/closed on the code host itself, Batch Changes will not be able to delete the branch. @@ -202,7 +202,7 @@ Batch Changes supports commit signing with both GitHub apps and with SSH keys. Commit signing with SSH keys is supported with Sourcegraph v6.2 or more and 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. +Sourcegraph can be configured to sign commits using SSH keys with user and administrator 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. @@ -223,9 +223,9 @@ 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. +To enable **commit signing as an administrator**, navigate to **Administration > 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) +![Administration 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 @@ -247,7 +247,7 @@ GitHub Apps are also the recommended way to [sync repositories on GitHub](/admin To create a GitHub App for commit signing and connect it to Sourcegraph: -1. Go to **Site admin > Batch Changes > Settings** on Sourcegraph. +1. Go to **Administration > Batch Changes > Settings** on Sourcegraph. ![The Batch Changes settings page on Sourcegraph, scrolled to show commit signing integrations](https://sourcegraphstatic.com/docs/images/administration/config/github-apps/github-apps-batches-list-dark.png) @@ -284,7 +284,7 @@ Once public, App can be installed in additional namespaces either from Sourcegra #### Installing from Sourcegraph -1. Go to **Site admin > Batch Changes > Settings** and click **Edit** on the App you want to install in another namespace. You'll be taken to the App details page. +1. Go to **Administration > Batch Changes > Settings** and click **Edit** on the App you want to install in another namespace. You'll be taken to the App details page. ![The GitHub App details page on Sourcegraph](https://sourcegraphstatic.com/docs/images/administration/config/github-apps/github-app-details-batches-dark.png) @@ -301,7 +301,7 @@ Once public, App can be installed in additional namespaces either from Sourcegra 1. Go to the GitHub App page. You can get here easily from Sourcegraph by clicking **View in GitHub** for the App you want to install in another namespace. 2. Click **Configure**, or go to **App settings > Install App**, and select the organization or user account you want to install the App on. 3. As before, you will be asked to review the App permissions and select which repositories the App can access before installing it in a namespace. Once you click **Install** and the setup completes, you will be redirected back to Sourcegraph. -4. GitHub App installations will be automatically synced in the background. Return to **Site admin > Batch Changes > Settings** and click **Edit** on the App you added the new installation for. You'll be taken to the App details page. Once synced, you will see the new installation listed, and you will be able to push signed commits for repositories in this namespace. +4. GitHub App installations will be automatically synced in the background. Return to **Administration > Batch Changes > Settings** and click **Edit** on the App you added the new installation for. You'll be taken to the App details page. Once synced, you will see the new installation listed, and you will be able to push signed commits for repositories in this namespace. ![The GitHub App details page on Sourcegraph, scrolled to show a second new installation](https://sourcegraphstatic.com/docs/images/administration/config/github-apps/github-app-post-multi-install-batches-dark.png) @@ -311,7 +311,7 @@ You can uninstall a GitHub App from a namespace or remove it altogether at any t To remove an installation in a single namespace, click **View in GitHub** for the installation you want to remove. If you are able to administer Apps in this namespace, you will see **Uninstall "[APP NAME]"** in the "Danger zone" at the bottom of the page. Click **Uninstall** to remove the App from this namespace. Sourcegraph will periodically sync installations in the background. It may temporarily throw errors related to the missing installation until the sync completes. You can check the GitHub App details page to confirm the installation has been removed. -To remove an App entirely, go to **Site admin > Batch Changes > Settings** and click **Remove** for the App you want to remove. You will be prompted to confirm you want to remove the App from Sourcegraph. Once removed from the Sourcegraph side, Sourcegraph will no longer communicate with your GitHub instance via the App unless explicitly reconnected. However, the App will still exist on GitHub unless manually deleted there, as well. +To remove an App entirely, go to **Administration > Batch Changes > Settings** and click **Remove** for the App you want to remove. You will be prompted to confirm you want to remove the App from Sourcegraph. Once removed from the Sourcegraph side, Sourcegraph will no longer communicate with your GitHub instance via the App unless explicitly reconnected. However, the App will still exist on GitHub unless manually deleted there, as well. ### GitHub App token use @@ -323,7 +323,7 @@ Installation access tokens are short-lived, non-refreshable tokens that give Sou ### Rejecting Unverified Commits -Admins can configure Batch Changes to error when it creates commits that are not signed. This can be done by enabling the `batchChanges.rejectUnverifiedCommits` setting in the site configuration: +Admins can configure Batch Changes to error when it creates commits that are not signed. This can be done by enabling the `batchChanges.rejectUnverifiedCommits` setting in the advanced configuration: ```json { @@ -334,7 +334,7 @@ Admins can configure Batch Changes to error when it creates commits that are not ## Custom Certificates -If you are using a self-signed certificate for your GitHub Enterprise instance, configure `tls.external` in the **Site configuration** with your certificate(s). +If you are using a self-signed certificate for your GitHub Enterprise instance, configure `tls.external` in the **Advanced configuration** with your certificate(s). ```json { @@ -353,13 +353,13 @@ However, if the user deletion is permanent, deleting both account and data, then ## Batch Spec Library -The Batch Spec Library offers curated examples and guided templates that make large-scale code modifications accessible to developers at every skill level. As a site admin you can manage the library. +The Batch Spec Library offers curated examples and guided templates that make large-scale code modifications accessible to developers at every skill level. As an administrator you can manage the library. The library distinguishes between [templates](#templates) and [examples](#library-examples). Examples are batch specs that are meant to be modified by power users who are comfortable with the batch spec syntax. Templates, on the other hand, are batch specs that contain variables that the user can provide data for through form fields without having to modify the batch spec code. Sourcegraph instances come with a couple of examples out of the box. You can use the GraphQL APIs to [manage the Batch Spec Library](#managing-the-batch-spec-library). -As a site admin, you can [feature records](#featured-records) to highlight the most useful templates and examples for your organization. +As an administrator, you can [feature records](#featured-records) to highlight the most useful templates and examples for your organization. ### Examples @@ -382,10 +382,10 @@ Variables can be used to replace any text in the batch spec except the batch cha ### Managing the Batch Spec Library - Site admins can manage the Batch Spec library in Sourcegraph v6.4 and more. + Administrators can manage the Batch Spec library in Sourcegraph v6.4 and more. -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. +Administrators 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") { @@ -410,7 +410,7 @@ batchSpecLibrary(first: 100) { ### Featured Records -Site-admins can mark a record as featured by either clicking the star button next to the list of library records or adding the `"featured"` [label](#labels) label with a GraphQL mutation. Featured records will automatically move to a section atop the remaining library records. +Administrators can mark a record as featured by either clicking the star button next to the list of library records or adding the `"featured"` [label](#labels) label with a GraphQL mutation. Featured records will automatically move to a section atop the remaining library records. ### Labels diff --git a/docs/admin/config/settings.mdx b/docs/admin/config/settings.mdx index c928cf5e8..7e43522dc 100644 --- a/docs/admin/config/settings.mdx +++ b/docs/admin/config/settings.mdx @@ -1,16 +1,18 @@ # Settings -Settings provide the ability to customize and control the Sourcegraph UI and user-specific features. They do not configure operational aspects of the instance (which are set in the [site configuration](/admin/config/site-config)). +Settings provide the ability to customize and control the Sourcegraph UI and user-specific features. They do not configure operational aspects of the instance (which are set in the [advanced configuration](/admin/config/site-config)). -Settings can be set at the global level (by site admins), the organization level (by organization members), and at the individual user level. +Settings can be set at the global level (by administrators), the organization level (by organization members), and at the individual user level. ![Settings-Cascade](https://storage.googleapis.com/sourcegraph-assets/Docs/settings-cascade.png) -## Editing global settings (for site admins) + -Global settings are found in **Site admin > Global settings** while links to organization and user settings are found in the user dropdown menu. +## Editing global settings (for administrators) -After setting or changing certain values in **Site admin > Global settings** the frontend will restart automatically or +Global settings are found in **Administration > Global settings** while links to organization and user settings are found in the user dropdown menu. + +After setting or changing certain values in **Administration > Global settings** the frontend will restart automatically or you might be asked to restart the frontend for the changes to take effect. In case of a Kubernetes deployment this can be done as follows: diff --git a/docs/admin/config/site-config.mdx b/docs/admin/config/site-config.mdx index 67d79ca6a..ee6c29947 100644 --- a/docs/admin/config/site-config.mdx +++ b/docs/admin/config/site-config.mdx @@ -1,21 +1,23 @@ -# Site configuration +# Advanced configuration -Site configuration defines how various Sourcegraph features behave. See the [full reference](#reference) below for a comprehensive list of site configuration options. +Advanced configuration defines how various Sourcegraph features behave. See the [full reference](#reference) below for a comprehensive list of advanced configuration options. ## Configuration overview [Go here](/admin/) for an overview of configuring Sourcegraph. -## View and edit site configuration + -Site admins can view and edit site configuration on a Sourcegraph instance: +## View and edit advanced configuration -1. Go to **User menu > Site admin**. -1. Open the **Configuration** page. (The URL is `https://sourcegraph.example.com/site-admin/configuration`.) +Administrators can view and edit advanced configuration on a Sourcegraph instance: + +1. Go to **User menu > Administration**. +1. Under **Configuration**, open **Advanced configuration**. (The URL is `https://sourcegraph.example.com/site-admin/configuration`.) ## Reference -All site configuration options and their default values are shown below. +All advanced configuration options and their default values are shown below. ### admin/config/site.schema.json @@ -1211,9 +1213,11 @@ All site configuration options and their default values are shown below. ``` {/* SCHEMA_SYNC_END: admin/config/site.schema.json */} -## Editing your site configuration if you cannot access the web UI + + +## Editing your advanced configuration if you cannot access the web UI -If you are having trouble accessing the web UI, you can make edits to your site configuration by editing the configuration directly. +If you are having trouble accessing the web UI, you can make edits to your advanced configuration by editing the configuration directly. ### Sourcegraph with Docker Compose and single-server Sourcegraph with Docker @@ -1249,7 +1253,7 @@ Then simply save your changes (type ctrl+x and y to exit ` ## If you are still encountering issues -You can check the container logs to see if you have made any typos or mistakes in editing the configuration file. If you are still encountering problems, you can save the default site configuration that comes with Sourcegraph (below) or contact support@sourcegraph.com with any questions you have. +You can check the container logs to see if you have made any typos or mistakes in editing the configuration file. If you are still encountering problems, you can save the default advanced configuration that comes with Sourcegraph (below) or contact support@sourcegraph.com with any questions you have. ```json { diff --git a/docs/admin/executors/executor-secrets.mdx b/docs/admin/executors/executor-secrets.mdx index 7112ec4f2..b23ecb20f 100644 --- a/docs/admin/executors/executor-secrets.mdx +++ b/docs/admin/executors/executor-secrets.mdx @@ -12,7 +12,7 @@ There are two types of secrets: - **Global secrets** - These secrets are defined by an admin in the site-admin interface and will be usable by every user on the Sourcegraph instance. + These secrets are defined by an admin in the Administration interface and will be usable by every user on the Sourcegraph instance. - **Namespaced secrets** @@ -34,7 +34,7 @@ Examples: ## Creating a new secret -To create a global secret, go to **Site-admin** > **Executors/Secrets** and click **Add secret**. +To create a global secret, go to **Administration** > **Executors/Secrets** and click **Add secret**. To create a user secret, go to your user profile from the navbar > **Settings** > **Executor secrets** and click **Add secret**. To create an org secret, go to the org profile from the navbar > **Executor secrets** and click **Add secret**. diff --git a/docs/admin/executors/index.mdx b/docs/admin/executors/index.mdx index b69f32bda..7e3409abd 100644 --- a/docs/admin/executors/index.mdx +++ b/docs/admin/executors/index.mdx @@ -55,8 +55,8 @@ Self-hosted executors authenticate to Sourcegraph with a shared secret: openssl rand -hex 32 ``` -1. Open **Site admin > Configuration > Advanced configuration**. -1. Set `executors.accessToken` to the generated secret and save the site configuration. +1. Open **Administration > Configuration > Advanced configuration**. +1. Set `executors.accessToken` to the generated secret and save the advanced configuration. ``` { "executors.accessToken": "" } @@ -64,16 +64,16 @@ Self-hosted executors authenticate to Sourcegraph with a shared secret: 1. Configure the same secret on each executor as `EXECUTOR_FRONTEND_PASSWORD`, or through the equivalent setting for its deployment method. -The executor authentication secret is not a Sourcegraph user access token and is not managed on the **Access tokens** page. See [Site configuration](/admin/config/site-config#view-and-edit-site-configuration) for more information about editing site configuration. +The executor authentication secret is not a Sourcegraph user access token and is not managed on the **Access tokens** page. See [Advanced configuration](/admin/config/site-config#view-and-edit-site-configuration) for more information about editing advanced configuration. ## Monitor executor instances The **Executor instances** page becomes available only after - `executors.accessToken` is configured in site configuration. + `executors.accessToken` is configured in advanced configuration. -Open **Site admin > Maintenance > Executor instances** to see executors that have connected to Sourcegraph. The page shows whether each executor is active, its Sourcegraph compatibility, and details including its hostname and installed runtime versions. +Open **Administration > Maintenance > Executor instances** to see executors that have connected to Sourcegraph. The page shows whether each executor is active, its Sourcegraph compatibility, and details including its hostname and installed runtime versions. ![Executor instances page showing active and inactive executors](https://storage.googleapis.com/sourcegraph-assets/docs/images/executors/executor-instances.png) @@ -83,7 +83,7 @@ Use this page to confirm that a new or upgraded executor is connected and report Executor secrets provide environment variables to jobs without placing secret values in a batch spec. Global secrets are available to every eligible job, while user and organization secrets apply only to jobs in their respective namespaces. Namespaced secrets override global secrets with the same name. -Site administrators manage global secrets under **Site admin > Batch Changes > Secrets**. Users and organization administrators manage their scoped secrets from the corresponding user or organization settings. +Administrators manage global secrets under **Administration > Batch Changes > Secrets**. Users and organization administrators manage their scoped secrets from the corresponding user or organization settings. Learn how to create, rotate, and remove [executor secrets](/admin/executors/executor-secrets). diff --git a/docs/admin/faq.mdx b/docs/admin/faq.mdx index 826766af3..e4f27ca7e 100644 --- a/docs/admin/faq.mdx +++ b/docs/admin/faq.mdx @@ -13,11 +13,11 @@ slower. ## How do I access Sourcegraph if my authentication provider experiences an outage? If you are using an external authentication provider and the provider experiences an outage, users -will be unable to sign into Sourcegraph. A site administrator can configure an alternate sign-in -method by modifying the `auth.providers` field in site configuration. However, the site -administrator may themselves be unable to sign in. If this is the case, then a site administrator +will be unable to sign into Sourcegraph. An administrator can configure an alternate sign-in +method by modifying the `auth.providers` field in advanced configuration. However, the site +administrator may themselves be unable to sign in. If this is the case, then an administrator can update the configuration if they have direct `docker exec` or `kubectl exec` access to the -Sourcegraph instance. Follow the [instructions to update the site config if the web UI is +Sourcegraph instance. Follow the [instructions to update the advanced configuration if the web UI is inaccessible](/admin/config/site-config#editing-your-site-configuration-if-you-cannot-access-the-web-ui). ## Sourcegraph is making unauthorized requests to the git server diff --git a/docs/admin/how-to/enable-experimental-feature.mdx b/docs/admin/how-to/enable-experimental-feature.mdx index e08a707e5..c8dfe8c0a 100644 --- a/docs/admin/how-to/enable-experimental-feature.mdx +++ b/docs/admin/how-to/enable-experimental-feature.mdx @@ -7,11 +7,11 @@ This document will take you through how to add, enable, or disable an experiment ## Prerequisites - This document assumes that Sourcegraph is installed -- Assumes you have site-admin privileges on the instance +- Assumes you have administrator privileges on the instance ## Steps to enable/disable -1. Navigate to Site Admin > Global settings in the UI, or follow this link format for your `externalUrl/site-admin/global-settings` +1. Navigate to Administration > Global settings in the UI, or follow this link format for your `externalUrl/site-admin/global-settings` 2. Scroll down to find where `experimentalFeatures` is located. Example: ```json @@ -23,11 +23,11 @@ This document will take you through how to add, enable, or disable an experiment 3. Locate the feature you would like to disable or enable, setting `true` for enable or `false` for disable. 4. If adding a feature, follow the format `"featureName": true,` -5. After changing the values in Site admin > Global settings, the frontend will either restart automatically or you might be asked to restart the frontend for the changes to take effect. -6. For more information, see [Editing global settings for site-admins](/admin/config/settings#editing-global-settings-for-site-admins) +5. After changing the values in Administration > Global settings, the frontend will either restart automatically or you might be asked to restart the frontend for the changes to take effect. +6. For more information, see [Editing global settings for administrators](/admin/config/settings#editing-global-settings-for-site-admins) ## Further resources - [Sourcegraph - Configuration Settings](/admin/config/settings) -- [Sourcegraph - Site configuration](/admin/config/site-config) +- [Sourcegraph - Advanced configuration](/admin/config/site-config) - Learn more about new experimental features on our [Blog](https://about.sourcegraph.com/blog) or Twitter [@sourcegraph](https://twitter.com/sourcegraph/) diff --git a/docs/admin/how-to/internal-github-repos.mdx b/docs/admin/how-to/internal-github-repos.mdx index 01fea5915..043838b47 100644 --- a/docs/admin/how-to/internal-github-repos.mdx +++ b/docs/admin/how-to/internal-github-repos.mdx @@ -6,7 +6,7 @@ This document will walk you through the steps of adding internal organization Gi This document assumes that you have: -- Site-admin level permissions on your Sourcegraph instance. +- Administrator level permissions on your Sourcegraph instance. - Access to your Sourcegraph deployment. - Internal Github repositories in your organization. diff --git a/docs/admin/how-to/manage-feature-flags-with-graphql.mdx b/docs/admin/how-to/manage-feature-flags-with-graphql.mdx index 27f27be56..476cb5a20 100644 --- a/docs/admin/how-to/manage-feature-flags-with-graphql.mdx +++ b/docs/admin/how-to/manage-feature-flags-with-graphql.mdx @@ -1,6 +1,6 @@ # How to manage feature flags with the GraphQL API -Some Sourcegraph instances do not expose the feature flag admin UI. In those cases, site admins can manage feature flags through the GraphQL API using the `src` CLI. +Some Sourcegraph instances do not expose the feature flag admin UI. In those cases, administrators can manage feature flags through the GraphQL API using the `src` CLI. ## Prerequisites diff --git a/docs/admin/how-to/mutate-user-api.mdx b/docs/admin/how-to/mutate-user-api.mdx index b643c99aa..1df5de302 100644 --- a/docs/admin/how-to/mutate-user-api.mdx +++ b/docs/admin/how-to/mutate-user-api.mdx @@ -6,7 +6,7 @@ This document walk you through the steps of using mutation queries to update or ## Prerequisites -- This document assumes that you have site-admin level permissions on your Sourcegraph instance +- This document assumes that you have administrator level permissions on your Sourcegraph instance - Assumes that you have set up your query token [via the steps here](/api/graphql#quickstart) ## Update a user @@ -129,7 +129,7 @@ Example: ## How to Import your code host and repositories into Sourcegraph using GraphQL -Sourcegraph site admins can use graphql API to import a code host as well as repositories into their Sourcegraph instance using `mutation.AddExternalService`. +Sourcegraph administrators can use graphql API to import a code host as well as repositories into their Sourcegraph instance using `mutation.AddExternalService`. This is as below: ``` diff --git a/docs/admin/how-to/remove-repo.mdx b/docs/admin/how-to/remove-repo.mdx index 3fe80b0c7..d3fbc1671 100644 --- a/docs/admin/how-to/remove-repo.mdx +++ b/docs/admin/how-to/remove-repo.mdx @@ -4,7 +4,7 @@ This document assumes that you have: -- site-admin level permissions on your Sourcegraph instance +- administrator level permissions on your Sourcegraph instance - access to your Sourcegraph deployment ## Steps to remove a repository from Sourcegraph @@ -20,7 +20,7 @@ Alternately, if a repository is synced from multiple code host connections you m ## Remove corrupted repository data from Sourcegraph 1. Exclude the repository as shown above from your code host(s) -1. Wait for the repository to disappear from the Repository Status Page located in your Site Admin panel. +1. Wait for the repository to disappear from the Repository Status Page located in your Administration panel. 1. Once you have confirmed the previous step has been completed, you will then exec into Gitserver (for docker-compose and kubernetes deployments) to locate the files that are associated with the repository. 1. Look for a directory with the name of the repository in the Gitserver. It should be located in the following file path: `data/repos/{name-of-code-host}/{name-of-repository}` 1. Delete the directory for that repository from the previous step. diff --git a/docs/admin/how-to/repo-not-updated.mdx b/docs/admin/how-to/repo-not-updated.mdx index b0894b2ac..5bbdd9b6a 100644 --- a/docs/admin/how-to/repo-not-updated.mdx +++ b/docs/admin/how-to/repo-not-updated.mdx @@ -4,7 +4,7 @@ A repository on Sourcegraph that fails to be updated could have different reason ## Prerequisites -This document assumes that you are a [site admin](/admin) and **do not** have `disableAutoGitUpdates` set to `true` in your site configuration. +This document assumes that you are a [administrator](/admin) and **do not** have `disableAutoGitUpdates` set to `true` in your advanced configuration. ## Steps to investigate diff --git a/docs/admin/how-to/site-admin-quickstart.mdx b/docs/admin/how-to/site-admin-quickstart.mdx index cc9e1595a..856bdc22c 100644 --- a/docs/admin/how-to/site-admin-quickstart.mdx +++ b/docs/admin/how-to/site-admin-quickstart.mdx @@ -1,8 +1,8 @@ -# Site Administration Quickstart +# Administration Quickstart -Administrating and managing a Sourcegraph instance is handled by Site Admins. These admins are typically responsible for deploying, managing, and configuring Sourcegraph for users on their instance. Site Admins have [elevated permissions](/admin/privileges) within their Sourcegraph instance. +Administrating and managing a Sourcegraph instance is handled by Administrators. These admins are typically responsible for deploying, managing, and configuring Sourcegraph for users on their instance. Administrators have [elevated permissions](/admin/privileges) within their Sourcegraph instance. -This guide will walk you through the features and functionalities available to you as a Site Admin and show how you can get started managing and maintaining your Sourcegraph instance. For detailed, in-depth information, please reference the [administration guides and docs](/admin/how-to/). +This guide will walk you through the features and functionalities available to you as an Administrator and show how you can get started managing and maintaining your Sourcegraph instance. For detailed, in-depth information, please reference the [administration guides and docs](/admin/how-to/). ## Getting Started @@ -28,27 +28,29 @@ Regardless of the deployment option you choose, Sourcegraph can be self-hosted l New versions of Sourcegraph are released monthly (with patches released in between, as needed). New updates are announced in the [Sourcegraph blog](https://about.sourcegraph.com/blog), and comprehensive update notes are available in the [technical changelog](https://sourcegraph.com/changelog/releases). -To check the current version of your instance, go to **User menu > Site admin > Updates**. +To check the current version of your instance, go to **User menu > Administration > Updates**. For more details on updating your instance, please refer to the [update docs](/self-hosted/updates/). ## Configuration -As a Site Admin, you have the ability to control and configure the various aspects of your instance. Including the code host connection(s), SSO, repository indexing, and the functionality of the instance itself. +As an Administrator, you have the ability to control and configure the various aspects of your instance. Including the code host connection(s), SSO, repository indexing, and the functionality of the instance itself. -### Site configuration + -At the heart of managing your Sourcegraph instance is Site configuration. Site config is a JSON file that defines how the various features and functionality within Sourcegraph are set up and configured. +### Advanced configuration -To access site config, go to **User menu > Site admin > Site configuration**. +At the heart of managing your Sourcegraph instance is Advanced configuration. Advanced configuration is a JSON file that defines how the various features and functionality within Sourcegraph are set up and configured. + +To access advanced configuration, go to **User menu > Administration > Advanced configuration**. ### Admin users configuration -If you need to add additional site admins, you can do so on the `/site-admin/users` page, under the actions for an individual user account. Any admin can revoke a user's admin privileges later using the same actions menu. +If you need to add additional administrators, you can do so on the `/site-admin/users` page, under the actions for an individual user account. Any admin can revoke a user's admin privileges later using the same actions menu. ### Connecting to code hosts -Sourcegraph supports connections to and repository syncing from any Git code host. Once connected, Sourcegraph will clone and index your repos so that users can search and navigate across them. To get started, go to **User menu > Site Admin > Manage code hosts > Add code host**. +Sourcegraph supports connections to and repository syncing from any Git code host. Once connected, Sourcegraph will clone and index your repos so that users can search and navigate across them. To get started, go to **User menu > Administration > Manage code hosts > Add code host**. Please reference the code host [documentation](/admin/code-hosts/) for detailed instructions on connecting to your code host. @@ -80,6 +82,6 @@ One key component to managing a Sourcegraph instance is having the ability to ob ### Viewing instance health and metrics -Alerts and metrics can be viewed and monitored in Grafana. To access the Grafana dashboard bundled with your Sourcegraph instance, go to **User menu > Site admin > Monitoring**. +Alerts and metrics can be viewed and monitored in Grafana. To access the Grafana dashboard bundled with your Sourcegraph instance, go to **User menu > Administration > Monitoring**. We also have an exhaustive [reference guide](/self-hosted/observability/dashboards) for understanding the available dashboards, and an [alert solutions guide](/self-hosted/observability/alerts) with descriptions and possible solutions for each alert that fires in Grafana. diff --git a/docs/admin/how-to/unknown-error-login.mdx b/docs/admin/how-to/unknown-error-login.mdx index a64411ff4..c39a7229e 100644 --- a/docs/admin/how-to/unknown-error-login.mdx +++ b/docs/admin/how-to/unknown-error-login.mdx @@ -5,7 +5,7 @@ This document will attempt to identify a common reason for an `Unknown Error` wh ## Prerequisites - This document assumes that Sourcegraph is set up and you are trying to login via an existing username and password -- For the step to check the site config, you will need to ask your organizations site-admin to check for you (this may not be required) +- For the step to check the advanced configuration, you will need to ask your organizations administrator to check for you (this may not be required) ## Steps to identify and remedy @@ -13,9 +13,9 @@ This document will attempt to identify a common reason for an `Unknown Error` wh 1. You are attempting to login with your username and password and see an `Unknown Error` message above the username and password boxes -2. This is often a result of an `http/https` protocol mismatch between what is in the site configuration for `externalURL`, and what the user is trying to log in to +2. This is often a result of an `http/https` protocol mismatch between what is in the advanced configuration for `externalURL`, and what the user is trying to log in to - - For example, if the protocol in the site configuration is set to `https://sourcegraph.example.com` + - For example, if the protocol in the advanced configuration is set to `https://sourcegraph.example.com` - And the user is trying to login at the `http://sourcegraph.example.com`, then this error can be displayed ### Things to check @@ -26,9 +26,9 @@ This document will attempt to identify a common reason for an `Unknown Error` wh 2. If you were trying to login with `http` protocol, try again with `https` instead -3. If you are still having issues, you can ask a site-admin to double check the `externalURL` configured in the Site configuration so you have the correct login landing page +3. If you are still having issues, you can ask an administrator to double check the `externalURL` configured in the Advanced configuration so you have the correct login landing page - See [Configuring the external URL](/self-hosted/url) ## Further resources -- [Sourcegraph - Site configuration](/admin/config/site-config) +- [Sourcegraph - Advanced configuration](/admin/config/site-config) diff --git a/docs/admin/index.mdx b/docs/admin/index.mdx index fa72f5c9b..57554f55e 100644 --- a/docs/admin/index.mdx +++ b/docs/admin/index.mdx @@ -8,7 +8,7 @@ seoPriority: 1.0 Supported on [Enterprise](/pricing/plans/enterprise) plans. -Sourcegraph administration is primarily managed by site administrators, who are responsible for the configuration of Sourcegraph instances for end users. For a comprehensive introduction to site administration, refer to our [quickstart guide](/admin/how-to/site-admin-quickstart). +Sourcegraph administration is primarily managed by administrators, who are responsible for the configuration of Sourcegraph instances for end users. For a comprehensive introduction to administration, refer to our [quickstart guide](/admin/how-to/site-admin-quickstart). ## Features @@ -28,8 +28,8 @@ Sourcegraph administration is primarily managed by site administrators, who are ## Configure Sourcegraph -- [Site Administrator Quickstart](/admin/how-to/site-admin-quickstart) -- [Site configuration](/admin/config/site-config) +- [Administration Quickstart](/admin/how-to/site-admin-quickstart) +- [Advanced configuration](/admin/config/site-config) - [Global and user settings](/admin/config/settings) - [Configuring Authorization and Authentication](/admin/config/authorization-and-authentication) - [User authentication](/admin/auth/) @@ -59,7 +59,7 @@ Sourcegraph administration is primarily managed by site administrators, who are ## Additional resources - [Migrate to Sourcegraph](/admin/migration/) -- [Full guide to site config options](/admin/config/site-config#auth-sessionExpiry) +- [Full guide to advanced configuration options](/admin/config/site-config#auth-sessionExpiry) - [Changelog](https://sourcegraph.com/changelog) to track releases and updates - [Configure webhooks](/admin/webhooks/) - [Configure search scopes](/code-search/working/snippets) diff --git a/docs/admin/licensing.mdx b/docs/admin/licensing.mdx index cd045671c..338058f75 100644 --- a/docs/admin/licensing.mdx +++ b/docs/admin/licensing.mdx @@ -13,11 +13,11 @@ License keys should not be shared across instances of Sourcegraph. If an additio ### What happens if our Sourcegraph license expires? -Sourcegraph will continue to function as normal, but all users will be signed out of Sourcegraph. Only site administrators will be able to sign into Sourcegraph so that they can enter a new license key. +Sourcegraph will continue to function as normal, but all users will be signed out of Sourcegraph. Only administrators will be able to sign into Sourcegraph so that they can enter a new license key. ### How can we update our license key? -Any current Site Admin can update your license key by going to Site Admin -> [Site configuration](/admin/config/site-config) +Any current Administrator can update your license key by going to Administration -> [Advanced configuration](/admin/config/site-config) These settings live in the JSON object, and you will need to navigate to the _licenseKey_ section of that object. diff --git a/docs/admin/migration/opengrok.mdx b/docs/admin/migration/opengrok.mdx index 5822b2c4d..ea613fc99 100644 --- a/docs/admin/migration/opengrok.mdx +++ b/docs/admin/migration/opengrok.mdx @@ -48,7 +48,7 @@ The following sections guide you through the migration process. We offer several methods for deploying Sourcegraph for various requirements—see [Getting started](/#getting-started) to learn more about how to get started with Sourcegraph. -Choose a deployment option and follow the instructions. When you've signed into your Sourcegraph instance as a site admin, continue to the next section. +Choose a deployment option and follow the instructions. When you've signed into your Sourcegraph instance as an administrator, continue to the next section. ### Configuring repositories @@ -65,7 +65,7 @@ Sourcegraph's "active" model lets it: To configure which repositories Sourcegraph will make available for searching and browsing: -- For repositories on popular code hosts, use the **Quick configure** actions on your Sourcegraph instance's site admin "Site configuration" page. +- For repositories on popular code hosts, use the **Quick configure** actions on your Sourcegraph instance's Administration "Advanced configuration" page. - For other repositories and for more information, see "[Add repositories](/admin/repo/add)" in the Sourcegraph documentation. When you've added repositories and confirmed that you can search and browse them, continue to the next section. @@ -98,7 +98,7 @@ After you've set Sourcegraph up, it's time to share it with your organization. S - Encourage installation of the [browser extension](/integration/browser-extension) to get Sourcegraph code navigation and search in your organization's existing code host. - Roll out the Chrome extension using [Google Workspace automatic installation](/integration/browser-extension/how-tos/google-workspace) to everyone in your organization. - Check the access logs for OpenGrok to see what users search for. Try searching for the same things on Sourcegraph, and ensure that you get the expected results. (Note: Sourcegraph's [search query syntax](/code-search/queries) differs from OpenGrok's.) -- Monitor your Sourcegraph instance's site admin "Analytics" page to see who's using it. Ask them for specific feedback. Also seek feedback from the most frequent users of OpenGrok. +- Monitor your Sourcegraph instance's Administration "Analytics" page to see who's using it. Ask them for specific feedback. Also seek feedback from the most frequent users of OpenGrok. If there are any blockers preventing your organization from switching to Sourcegraph, we'd love to hear from you so we can address them. diff --git a/docs/admin/oauth-apps.mdx b/docs/admin/oauth-apps.mdx index 568c7ae0f..f8e8f96e9 100644 --- a/docs/admin/oauth-apps.mdx +++ b/docs/admin/oauth-apps.mdx @@ -15,7 +15,7 @@ OAuth Apps are in compliance with standards including [RFC 6749](https://tools.i OAuth Apps and service-account M2M credentials both use Sourcegraph's OAuth server, but they are different client types for different jobs: - - OAuth Apps created in **Site admin > OAuth clients** are for apps acting on + - OAuth Apps created in **Administration > OAuth clients** are for apps acting on behalf of a user. They support `authorization_code` and `refresh_token`, and public clients also support the device authorization flow. @@ -35,9 +35,9 @@ Consider using **M2M (client-credentials) service-account tokens** or traditiona ## Creating an OAuth App -Site admins can create OAuth Apps in the site admin area: +Administrators can create OAuth Apps in the Administration area: -1. Navigate to **Site admin > OAuth clients** +1. Navigate to **Administration > OAuth clients** 2. Click **Create OAuth client** 3. Provide the following information: @@ -127,7 +127,7 @@ OAuth App can request only the scopes selected on that client. ## OAuth Flow Examples -The first three flows below are for OAuth Apps created in **Site admin > OAuth +The first three flows below are for OAuth Apps created in **Administration > OAuth clients**. The `client_credentials` example is included for completeness, but it only works with M2M credentials created for a service account. @@ -288,7 +288,7 @@ curl -X POST https://sourcegraph.example.com/.auth/idp/oauth/token \ -The client credentials flow is designed for server-to-server authentication without user interaction. It is not available for OAuth Apps created in **Site admin > OAuth clients**. Instead, service accounts create separate M2M (machine-to-machine) credentials that use this flow. You can create M2M credentials in the service account settings under **Access tokens > M2M credentials**. +The client credentials flow is designed for server-to-server authentication without user interaction. It is not available for OAuth Apps created in **Administration > OAuth clients**. Instead, service accounts create separate M2M (machine-to-machine) credentials that use this flow. You can create M2M credentials in the service account settings under **Access tokens > M2M credentials**. 1. **Token Request** (no user interaction required): diff --git a/docs/admin/organizations.mdx b/docs/admin/organizations.mdx index c3fe3719d..4e19fa26f 100644 --- a/docs/admin/organizations.mdx +++ b/docs/admin/organizations.mdx @@ -4,9 +4,9 @@ Organizations are named groups of users with an associated JSON settings file (w To create an organization, go to `https://sourcegraph.example.com/organizations/new` on your Sourcegraph instance (or, from any page, click your username and then **New organization**). -You (and any other organization members, and any site admin) may add or remove members from the organization's members page at `https://sourcegraph.example.com/organizations/[org-name]/members`. +You (and any other organization members, and any administrator) may add or remove members from the organization's members page at `https://sourcegraph.example.com/organizations/[org-name]/members`. -To automatically join all users on your instance to a specific organization, create the organization first and then set the `auth.userOrgMap` [site configuration](/admin/config/site-config) option: +To automatically join all users on your instance to a specific organization, create the organization first and then set the `auth.userOrgMap` [advanced configuration](/admin/config/site-config) option: ```json { @@ -20,4 +20,4 @@ To automatically join all users on your instance to a specific organization, cre } ``` -> NOTE: Users will not be automatically populated to the org immediately after adding `auth.userOrgMap` to your site config json. Instead the org will be populated with all users upon the creation of any new user. +> NOTE: Users will not be automatically populated to the org immediately after adding `auth.userOrgMap` to your advanced configuration json. Instead the org will be populated with all users upon the creation of any new user. diff --git a/docs/admin/outbound-request-log.mdx b/docs/admin/outbound-request-log.mdx index 5e3340ce5..e744e3d5b 100644 --- a/docs/admin/outbound-request-log.mdx +++ b/docs/admin/outbound-request-log.mdx @@ -1,16 +1,16 @@ # Outbound request log -On the **Outbound requests** page, site admins can see all outbound requests generated by an instance. The page makes it easy to quickly see how Sourcegraph interacts with other systems, such as code hosts, without manually digging into logs, and is especially useful when debugging. +On the **Outbound requests** page, administrators can see all outbound requests generated by an instance. The page makes it easy to quickly see how Sourcegraph interacts with other systems, such as code hosts, without manually digging into logs, and is especially useful when debugging. ![UI screenshot](https://storage.googleapis.com/sourcegraph-assets/Docs/outbound-request-log.png) ## Prerequisites -This document assumes you are a [site admin](/admin/). +This document assumes you are a [administrator](/admin/). ## Enabling the logs -This feature is off by default. You can enable it by setting `outboundRequestLogLimit` to a non-zero value in the [site config](/admin/config/site-config#outboundRequestLogLimit). The recommended value is `50`. +This feature is off by default. You can enable it by setting `outboundRequestLogLimit` to a non-zero value in the [advanced configuration](/admin/config/site-config#outboundRequestLogLimit). The recommended value is `50`. You can later disable it by setting `outboundRequestLogLimit` to `0`, or by removing the setting entirely. @@ -40,7 +40,7 @@ To recreate a request for debugging, you can copy the cURL command for any reque Keep in mind that some headers might be redacted (you'll see the word "REDACTED" in their place), in which case you'll need to add the missing pieces manually. -Note: You can set the `redactOutboundRequestHeaders` [site config](/admin/config/site-config#redactOutboundRequestHeaders) option to `false` to disable the redaction of headers and make the "Copy curl" function more convenient. But for security reasons, this setting is only respected in development environments. +Note: You can set the `redactOutboundRequestHeaders` [advanced configuration](/admin/config/site-config#redactOutboundRequestHeaders) option to `false` to disable the redaction of headers and make the "Copy curl" function more convenient. But for security reasons, this setting is only respected in development environments. ## Troubleshooting diff --git a/docs/admin/permissions/api.mdx b/docs/admin/permissions/api.mdx index dce8b8094..a3040c10e 100644 --- a/docs/admin/permissions/api.mdx +++ b/docs/admin/permissions/api.mdx @@ -18,11 +18,11 @@ In that case, it might be less resource intensive to sync the permissions from e It is important to note, that when using explicit permissions API, the permissions are written to the database as provided, without further verification that such permissions do exist on the code host side. -Keeping the permissions in sync and fresh is the responsibility of the site admins. +Keeping the permissions in sync and fresh is the responsibility of the administrators. ## Configuration -To enable the permissions API, add the following to the [site configuration](/admin/config/site-config): +To enable the permissions API, add the following to the [advanced configuration](/admin/config/site-config): ```json "permissions.userMapping": { @@ -36,7 +36,7 @@ The `bindID` value specifies how to uniquely identify users when setting permiss - `username`: You can [set permissions](#setting-repository-permissions-for-users) for users by specifying their Sourcegraph usernames. Using usernames is **preferred**, as usernames are required to be unique for each user. - `email`: You can [set permissions](#setting-repository-permissions-for-users) for users by specifying their email addresses (which must be verified primary emails associated with their Sourcegraph user account). This method can lead to unexpected results if there are multiple Sourcegraph user accounts with the same verified email address. Also, the email address is case-sensitive, so it should be exactly the same as set on the sourcegraph UI. -After you enable the permissions API, you must [set permissions](#setting-repository-permissions-for-users) to allow users to view repositories (site admins bypass all permissions checks and can always view all repositories). +After you enable the permissions API, you must [set permissions](#setting-repository-permissions-for-users) to allow users to view repositories (administrators bypass all permissions checks and can always view all repositories). > NOTE: If you were previously using [permissions syncing](/admin/permissions/syncing), e.g. syncing permissions from Github, then those permissions are used as the initial state after enabling explicit permissions. Otherwise, the initial state is for all repositories to have an empty set of authorized users, so users will not be able to view any repositories. @@ -84,7 +84,7 @@ mutation { } ``` -Now, only the users specified in the `userPermissions` parameter will be allowed to view the repository. Sourcegraph automatically enforces these permissions for all operations. (Site admins bypass all permissions checks by default. See the [Site administrators](/admin/permissions/#site-administrators) section) +Now, only the users specified in the `userPermissions` parameter will be allowed to view the repository. Sourcegraph automatically enforces these permissions for all operations. (Administrators bypass all permissions checks by default. See the [Administrators](/admin/permissions/#site-administrators) section) You can call `setRepositoryPermissionsForUsers` repeatedly to set permissions for each repository, and whenever you want to change the list of authorized users. @@ -94,7 +94,7 @@ You can call `setRepositoryPermissionsForUsers` repeatedly to set permissions fo Sourcegraph supports permissions on a per-file/directory basis. -To enable the sub-repo permissions API, add the following to the [site configuration](/admin/config/site-config): +To enable the sub-repo permissions API, add the following to the [advanced configuration](/admin/config/site-config): ```json "experimentalFeatures": { diff --git a/docs/admin/permissions/index.mdx b/docs/admin/permissions/index.mdx index d0d6ddf9b..fa7dc07f9 100644 --- a/docs/admin/permissions/index.mdx +++ b/docs/admin/permissions/index.mdx @@ -107,16 +107,18 @@ in Sourcegraph. To have permission syncing available, you need a valid Sourcegraph license key. Without a license, Sourcegraph will not enforce repository permissions and each repository will be treated as public - any user that has access to Sourcegraph will be able to access it. -## Site administrators + -By default, site-admins bypass all of the permissions checks. Which means, all site admins are able to -view all the repositories by default. The default can be changed by setting the site config +## Administrators + +By default, administrators bypass all of the permissions checks. Which means, all administrators are able to +view all the repositories by default. The default can be changed by setting the advanced configuration option `authz.enforceForSiteAdmins` to `true`. -> NOTE: However, we recommend to be cautious with this option, as it might make some operations for site admins more complicated or impossible. +> NOTE: However, we recommend to be cautious with this option, as it might make some operations for administrators more complicated or impossible. E.g. trying to figure out if a specific repository is syncing source code to Sourcegraph correctly -might become an impossible task if the site admin cannot access that repository. +might become an impossible task if the administrator cannot access that repository. ## Permissions mechanisms in parallel diff --git a/docs/admin/permissions/syncing.mdx b/docs/admin/permissions/syncing.mdx index 20dcf46c8..ec730fb2c 100644 --- a/docs/admin/permissions/syncing.mdx +++ b/docs/admin/permissions/syncing.mdx @@ -240,7 +240,7 @@ firing huge amounts of requests to the code host. ## Configuration -There are variety of options in the site configuration to tune how the permissions sync requests are +There are variety of options in the advanced configuration to tune how the permissions sync requests are scheduled. Default values are shown below: ```json @@ -321,7 +321,7 @@ In some cases, user-centric and repo-centric permission sync can conflict. This > IMPORTANT: Disabling repo-centric permission sync can break your permission setup depending on your code host and user authentication method. Contact Sourcegraph support before disabling repo-centric permission sync. -To completely disable repo-centric permission sync scheduling, use this site configuration: +To completely disable repo-centric permission sync scheduling, use this advanced configuration: ```json { diff --git a/docs/admin/pings.mdx b/docs/admin/pings.mdx index 46e050a2e..867d0d661 100644 --- a/docs/admin/pings.mdx +++ b/docs/admin/pings.mdx @@ -1,6 +1,6 @@ # Pings -Sourcegraph periodically sends a ping to `pings.sourcegraph.com` to help our product and customer teams. It sends only the high-level, aggregated data below. It never sends code, repository names, usernames, or any other specific data. To learn more, go to the **Site admin > Pings** page on your instance (the URL is `https://sourcegraph.example.com/site-admin/pings`). +Sourcegraph periodically sends a ping to `pings.sourcegraph.com` to help our product and customer teams. It sends only the high-level, aggregated data below. It never sends code, repository names, usernames, or any other specific data. To learn more, go to the **Administration > Pings** page on your instance (the URL is `https://sourcegraph.example.com/site-admin/pings`). Sourcegraph will also periodically perform a license verification check, to verify the validity of the configured Sourcegraph license. Tampering with these checks, or preventing them from occurring, will cause Sourcegraph to disable many features until a successful check is completed. Certain Enterprise licenses can request to be exempt from these license verification checks. @@ -13,7 +13,7 @@ Sourcegraph aggregates usage and performance metrics for some product features i ### List of attributes - Randomly generated site identifier -- The email address of the initial site installer (or if deleted, the first active site admin), to know who to contact regarding sales, product updates, security updates, and policy updates +- The email address of the initial site installer (or if deleted, the first active administrator), to know who to contact regarding sales, product updates, security updates, and policy updates - The external URL of the instance (e.g. "https://sourcegraph.example.com") - The IP address of the instance (e.g. "172.xx.xx.xx") - Sourcegraph version string (e.g. "vX.X.X") @@ -198,7 +198,7 @@ Sourcegraph aggregates usage and performance metrics for some product features i - Embeddings - Provider name - Model name (only for "sourcegraph" provider) -- Whether Cody context filters are configured in the site config (true/false) +- Whether Cody context filters are configured in the advanced configuration (true/false) ## Allowlist IPs / CIDR Ranges for Sourcegraph @@ -241,7 +241,7 @@ Sourcegraph telemetry pings are handled by a goroutine running on Sourcegraph's ### Misconfigured update.channel -The most common scenario in which Sourcegraph stops sending pings is a change to the `update.channel` setting in an instance's [site config](/admin/config/site-config) +The most common scenario in which Sourcegraph stops sending pings is a change to the `update.channel` setting in an instance's [advanced configuration](/admin/config/site-config) ``` "update.channel": "release", @@ -269,6 +269,6 @@ Example: ### Looking for errors in the logs -If the `update.check` is running, and the site config is correctly configured, then it may be the case that `pgsql` is failing to return data from the SQL queries to the `frontend`. Check out the frontend logs for logs tagged [`telemetry: updatecheck failed`](https://sourcegraph.com/search?q=context:global+repo:%5Egithub%5C.com/sourcegraph/sourcegraph%24+file:%5Ecmd/frontend/internal/app/updatecheck/client%5C.go+telemetry:+updatecheck+failed&patternType=literal). +If the `update.check` is running, and the advanced configuration is correctly configured, then it may be the case that `pgsql` is failing to return data from the SQL queries to the `frontend`. Check out the frontend logs for logs tagged [`telemetry: updatecheck failed`](https://sourcegraph.com/search?q=context:global+repo:%5Egithub%5C.com/sourcegraph/sourcegraph%24+file:%5Ecmd/frontend/internal/app/updatecheck/client%5C.go+telemetry:+updatecheck+failed&patternType=literal). If issues persist, please reach out to a team member for support at support@sourcegraph.com diff --git a/docs/admin/privileges.mdx b/docs/admin/privileges.mdx index b675c552d..bc3622d03 100644 --- a/docs/admin/privileges.mdx +++ b/docs/admin/privileges.mdx @@ -1,22 +1,22 @@ -# Site administrator privileges +# Administrator privileges -Site administrators have full administrative access to the Sourcegraph instance. In many cases, they also control the deployment environment. Special privileges are granted to site-admin users. +Administrators have full administrative access to the Sourcegraph instance. In many cases, they also control the deployment environment. Special privileges are granted to administrator users. ## Access to all repositories -Site administrators are able to access all repositories on the Sourcegraph instance and manage the settings of individual repositories. +Administrators are able to access all repositories on the Sourcegraph instance and manage the settings of individual repositories. ## Access to all GraphQL APIs -Site administrators are able to access all GraphQL APIs of the Sourcegraph instance, including special GraphQL APIs that require a site-admin access token. +Administrators are able to access all GraphQL APIs of the Sourcegraph instance, including special GraphQL APIs that require an administrator access token. ## Impersonate regular users -Site administrators are able to impersonate regular users in two ways: +Administrators are able to impersonate regular users in two ways: 1. View and update the settings of any user. 2. Initiate GraphQL API calls on behalf of any other user. ## Receive site alerts -Site administrators see update notifications and other site-level alerts (visible as a banner across the top of the screen) that may be invisible to non-admin users. +Administrators see update notifications and other site-level alerts (visible as a banner across the top of the screen) that may be invisible to non-admin users. diff --git a/docs/admin/repo/add.mdx b/docs/admin/repo/add.mdx index 8b4312787..bbf45e674 100644 --- a/docs/admin/repo/add.mdx +++ b/docs/admin/repo/add.mdx @@ -14,7 +14,7 @@ ### Repositories not showing up -If your repositories are not showing up, check the site admin **Repositories** page on Sourcegraph (and ensure you're logged in as an admin). +If your repositories are not showing up, check the Administration **Repositories** page on Sourcegraph (and ensure you're logged in as an admin). If nothing informative is visible there, check for error messages related to communication with your code host's API in the logs from: - [Docker Compose](/self-hosted/deploy/docker-compose/) and [Kubernetes](/self-hosted/deploy/kubernetes/): the logs from the `worker` container/pod diff --git a/docs/admin/repo/auth.mdx b/docs/admin/repo/auth.mdx index a8c1184e0..a7ea9cf22 100644 --- a/docs/admin/repo/auth.mdx +++ b/docs/admin/repo/auth.mdx @@ -2,7 +2,7 @@ If authentication (HTTP(S) or SSH) is required to `git clone` a repository then you must provide credentials to the container. -First, ensure your **Site admin > Manage code hosts** code host configuration is configured to use SSH. For example, by setting the `gitURLType` field to "ssh". Alternatively, you may use the "Generic Git host" code host type, which allows you to directly specify Git repository URLs for cloning. +First, ensure your **Administration > Manage code hosts** code host configuration is configured to use SSH. For example, by setting the `gitURLType` field to "ssh". Alternatively, you may use the "Generic Git host" code host type, which allows you to directly specify Git repository URLs for cloning. Then, you need to supply the SSH keys and passphrase to Sourcegraph if applicable. You have two options: diff --git a/docs/admin/repo/perforce.mdx b/docs/admin/repo/perforce.mdx index b512ef25a..c9bd56a12 100644 --- a/docs/admin/repo/perforce.mdx +++ b/docs/admin/repo/perforce.mdx @@ -8,9 +8,9 @@ Sourcegraph supports [Perforce Helix](https://www.perforce.com/solutions/version Perforce depots can be added to a Sourcegraph instance by adding the appropriate [code host connection](/admin/code-hosts/). -To enable Perforce code host connections, a site admin must: +To enable Perforce code host connections, an administrator must: -1. Go to **Site admin > Manage code hosts > Add code host** +1. Go to **Administration > Manage code hosts > Add code host** 1. Scroll down the list of supported code hosts and select **Perforce**. @@ -130,7 +130,7 @@ File-level permissions eliminate the need for [syncing subdirectories to match p To enable file-level permissions: -1. Add the following entry to your site configuration file: +1. Add the following entry to your advanced configuration file: ```json { @@ -178,7 +178,7 @@ To ensure Sourcegraph handles host rules according to your requirements, you hav ##### Enforcing host rules -If you want Sourcegraph to enforce host-specific permissions, you need to enable IP restriction enforcement in your [site configuration](/admin/config/site-config): +If you want Sourcegraph to enforce host-specific permissions, you need to enable IP restriction enforcement in your [advanced configuration](/admin/config/site-config): ```json { @@ -220,7 +220,7 @@ With this setting, Sourcegraph will ignore any rules with a host other than `*`, - As long as a user has been granted at least `Read` permissions in Perforce they will be able to view content in Sourcegraph. - As a special case, commits in which a user does not have permissions to read any files are hidden. If a user can read a subset of files in a commit, only those files are shown. - [file-level permissions must be disabled for Batch Changes to work](#known-issues-and-limitations). -- Setting `authz.enforceForSiteAdmins` to `true` in the site configuration will enforce permissions for admin users. They may not be able to see repositories and their contents if their Sourcegraph user account email does not match with their email on the Perforce server. +- Setting `authz.enforceForSiteAdmins` to `true` in the advanced configuration will enforce permissions for admin users. They may not be able to see repositories and their contents if their Sourcegraph user account email does not match with their email on the Perforce server. ## Configuration @@ -305,7 +305,7 @@ The following experimental features are available for Perforce depots. These are Note: When enabling changelist IDs in URLs for the first time, Perforce depots can be unavailable for a few minutes on the Sourcegraph instance, due to the initial mapping of changelist IDs to generated commit ID happening in the background. If you have a large number of Perforce depots, we recommend proceeding with the following steps in a maintenance window in which you don't expect large amounts of traffic on your Sourcegraph instance. -Add `"perforceChangelistMapping": "enabled",` to `experimentalFeatures` in the [site configuration](/admin/config/site-config): +Add `"perforceChangelistMapping": "enabled",` to `experimentalFeatures` in the [advanced configuration](/admin/config/site-config): ```json { @@ -345,11 +345,11 @@ repo:^Talkhouse/main$ rev:changelist/123 text to find To support CLs natively in the URLs, Sourcegraph performs background computation after syncing the contents of a depot. That's done by parsing each generated commit to retrieve the corresponding CL ID and store it in the `repo_commits_changelists` table. This is currently performed on only one depot at a time and we are working to support this for multiple depots in parallel in an upcoming release. -Additionally, while removing a depot from a code host config will mark it as "deleted", the mapped information will **not** be deleted to prevent forced re-computation after an accidental removal of depot from a code host config. Similarly recloning a depot will **not** trigger a computation of all the CLs from the beginning of the depot's source control history. If site admins are recloning or deleting and re-adding a depot to Sourcegraph as a result of history rewrite of a depot in Perforce, they should get in [touch with us](mailto:support@sourcegraph.com) for next steps. +Additionally, while removing a depot from a code host config will mark it as "deleted", the mapped information will **not** be deleted to prevent forced re-computation after an accidental removal of depot from a code host config. Similarly recloning a depot will **not** trigger a computation of all the CLs from the beginning of the depot's source control history. If administrators are recloning or deleting and re-adding a depot to Sourcegraph as a result of history rewrite of a depot in Perforce, they should get in [touch with us](mailto:support@sourcegraph.com) for next steps. ### Batch Changes support for Perforce depots -Add `"batchChanges.enablePerforce": true` to `experimentalFeatures` in the [site configuration](/admin/config/site-config): +Add `"batchChanges.enablePerforce": true` to `experimentalFeatures` in the [advanced configuration](/admin/config/site-config): ```json { diff --git a/docs/admin/repo/recording.mdx b/docs/admin/repo/recording.mdx index 53d28771d..23cb18b40 100644 --- a/docs/admin/repo/recording.mdx +++ b/docs/admin/repo/recording.mdx @@ -5,7 +5,7 @@ instance.

-Command recording allows site admins to view all git operations executed on a repository. When enabled, Sourcegraph will record metadata about all git commands run on a repository in Redis, including: +Command recording allows administrators to view all git operations executed on a repository. When enabled, Sourcegraph will record metadata about all git commands run on a repository in Redis, including: - Command executed (with sensitive information redacted) - Execution time @@ -19,7 +19,7 @@ This provides visibility into git operations performed by Sourcegraph on a repos To enable command recording: -- Go to [**Site Admin > Site Configuration**](/admin/config/site-config) +- Go to [**Administration > Advanced Configuration**](/admin/config/site-config) - Add a `gitRecorder` object to the configuration object ```json @@ -41,7 +41,7 @@ To enable command recording: } ``` -Once enabled, site admins can view recorded commands for a repository via the repository's settings page in the Site Admin UI. +Once enabled, administrators can view recorded commands for a repository via the repository's settings page in the Administration UI. Recorded commands include **start time**, **duration**, **exit status**, **command executed**, **directory**, and **output**. Sensitive information like usernames, passwords, and tokens are automatically redacted from the command and output. diff --git a/docs/admin/repo/update-frequency.mdx b/docs/admin/repo/update-frequency.mdx index e839f8af3..51da7a331 100644 --- a/docs/admin/repo/update-frequency.mdx +++ b/docs/admin/repo/update-frequency.mdx @@ -16,7 +16,7 @@ If you wish to control how frequently repositories are discovered or how frequen - Code host configuration: see [Rate limits](/admin/code-hosts/rate-limits) -- Site configuration: [repoListUpdateInterval](/admin/config/site-config#repoListUpdateInterval) controls how frequently we check the code host _for new repositories_ in minutes. +- Advanced configuration: [repoListUpdateInterval](/admin/config/site-config#repoListUpdateInterval) controls how frequently we check the code host _for new repositories_ in minutes. > NOTE: Internal rate limiting is currently only enforced for HTTP requests to code hosts. That means it's used when, for example, syncing changesets in [batch changes](/batch-changes/), repository permissions and repository metadata from code hosts. @@ -31,10 +31,10 @@ You may also choose to disable automatic Git updates entirely and instead [confi > NOTE: [Instrumentation](/admin/faq#i-am-getting-error-cluster-information-not-available-in-the-instrumentation-page-what-should-i-do) (where Repo Updater State resides) is only available for Kubernetes instances. -**Repo Updater State** is a useful debugging tool for site admins to monitor: +**Repo Updater State** is a useful debugging tool for administrators to monitor: - **Schedule**: The schedule of when repositories get enqueued into the Update Queue. - **Update Queue**: A priority queue of repositories to update. A worker continuously dequeues them and sends updates to gitserver. - **Sync jobs**: The current list of external service sync jobs, ordered by start date descending -Site admin: Go to **Site admin > Instrumentation (under Maintenance) > worker > Repo Updater State** +Administrator: Go to **Administration > Instrumentation (under Maintenance) > worker > Repo Updater State** diff --git a/docs/admin/repo/webhooks.mdx b/docs/admin/repo/webhooks.mdx index ca559d51f..4fc89de4f 100644 --- a/docs/admin/repo/webhooks.mdx +++ b/docs/admin/repo/webhooks.mdx @@ -20,7 +20,7 @@ curl -XPOST \ ## Disabling built-in repo updating -Sourcegraph will periodically ask your code host to list its repositories via its HTTP API to _discover repositories_. You can control how often this occurs by changing [`repoListUpdateInterval`](/admin/config/site-config) in the site config. +Sourcegraph will periodically ask your code host to list its repositories via its HTTP API to _discover repositories_. You can control how often this occurs by changing [`repoListUpdateInterval`](/admin/config/site-config) in the advanced configuration. For repositories that Sourcegraph is already aware of, it will periodically perform background git repository updates. You can disable this if needed by setting [`disableAutoGitUpdates`](/admin/config/site-config) to `true`, then the repository will only be updated when the webhook is used or when a user visits the repository directly. diff --git a/docs/admin/scim.mdx b/docs/admin/scim.mdx index 212d7f7dc..f38edc747 100644 --- a/docs/admin/scim.mdx +++ b/docs/admin/scim.mdx @@ -50,13 +50,13 @@ To configure: (This command generates a random base64 string with more characters than required (342 characters) and then filters out non-alphanumeric characters. Finally, it trims the output to 255 characters. The reason we generate a longer string is to account for the fact that the base64 encoding has non-alphanumeric characters, which are removed by the tr command.) -2. Add the following line to your [site configuration](/admin/config/site-config): +2. Add the following line to your [advanced configuration](/admin/config/site-config): ``` "scim.authToken": "{your token}" ``` -3. If you use Microsoft Entra ID, add the following setting to your site config: +3. If you use Microsoft Entra ID, add the following setting to your advanced configuration: ``` "scim.identityProvider": "Azure AD" @@ -99,7 +99,7 @@ To set up user provisioning in [Okta](https://help.okta.com/en-us/Content/Topics 1. Set "Unique identifier field for users" to `userName` 1. Check the first three items in `Supported provisioning actions`: "Import New Users and Profile Updates", "Push New Users", and "Push Profile Updates". 1. Set "Authentication mode" to "HTTP Header" -1. Under "HTTP Header", paste the same alphanumeric bearer token you used in your site config. +1. Under "HTTP Header", paste the same alphanumeric bearer token you used in your advanced configuration. 1. Click "Test Connection Configuration" (first four items should be green—the user-related ones), then "Save". 1. Switch to "Provisioning" → "To App" and click "Edit". Enable "Create Users", "Update User Attributes" and "Deactivate Users". diff --git a/docs/admin/search.mdx b/docs/admin/search.mdx index 9f7a3a455..468c8ad72 100644 --- a/docs/admin/search.mdx +++ b/docs/admin/search.mdx @@ -10,7 +10,7 @@ By default, files larger than 1 MB are excluded from search results. Use the [se ### Maximum timeout -By default, users cannot set a search timeout larger than 1 minute. Sourcegraph admins can increase the maximum timeout through site configuration: +By default, users cannot set a search timeout larger than 1 minute. Sourcegraph admins can increase the maximum timeout through advanced configuration: ```json "search.limits": { @@ -76,7 +76,7 @@ Sourcegraph indexes the code on the default branch of each repository. This spee To view which files are skipped during indexing, visit the repository settings page and click on **Indexing**. -To force the indexer to include specific files (like `yarn.lock` or other large text files) that are otherwise skipped, add their file path or a glob pattern to the [search.largeFiles](/admin/search#maximum-file-size) setting in your site configuration and reindex the repository. Note that files must still be valid UTF-8 to be indexed, even if added to `search.largeFiles`. +To force the indexer to include specific files (like `yarn.lock` or other large text files) that are otherwise skipped, add their file path or a glob pattern to the [search.largeFiles](/admin/search#maximum-file-size) setting in your advanced configuration and reindex the repository. Note that files must still be valid UTF-8 to be indexed, even if added to `search.largeFiles`. For large deployments we recommend horizontally scaling indexed search. You can do this by adjusting the [number of replicas](/self-hosted/deploy/kubernetes/configure). Sourcegraph shards repository indexes across replicas. When the replica count changes Sourcegraph will slowly rebalance indexes to ensure availability of existing indexes. @@ -90,7 +90,7 @@ The resource requirements for indexed search vary considerably based on the text Sourcegraph always maintains an index of the source code on your default branch. Some organizations have other branches that are regularly searched. To speed up search for those branches, Sourcegraph can be configured to index up to 64 branches per repository. -You can configure indexed branches in site configuration under the `experimentalFeatures.search.index.branches` setting. For example: +You can configure indexed branches in advanced configuration under the `experimentalFeatures.search.index.branches` setting. For example: ```json "experimentalFeatures": { diff --git a/docs/admin/security-event-logs.mdx b/docs/admin/security-event-logs.mdx index 7db2cb09d..a245b6467 100644 --- a/docs/admin/security-event-logs.mdx +++ b/docs/admin/security-event-logs.mdx @@ -12,7 +12,7 @@ This guide goes into the details of Security Event Logging in Sourcegraph - Getting a full picture of how a user moves through the application, in a single location, is crucial for many reasons. - When a user takes an action on sensitive information within the application, this should be logged to make sure it can be retraced to the user and time. - In Sourcegraph application, these sensitive actions are logged as "security event" with relevant information included in the log output. -- These logs can be enabled/disabled as well as the location can be set via the [site config settings](./audit-log#configuring) +- These logs can be enabled/disabled as well as the location can be set via the [advanced configuration settings](./audit-log#configuring) - Previously, we were logging a very selective set of actions. However, through various analyses, it was determined that there were some gaps in creating a full picture. - New event types are constantly being added to fill these gaps. @@ -52,13 +52,13 @@ This guide goes into the details of Security Event Logging in Sourcegraph ``` -- The function sends the log event it creates to be pushed to the right location based on the site-config settings +- The function sends the log event it creates to be pushed to the right location based on the advanced configuration settings - The function also checks to make sure that marshaling the arguments does not cause as error ## How to find security events in logs - Security events are logged with all the relevant information associated with the actions -- Depending on the location of the log destination set in the site config, the event log can be either found in the application log output or in the database or both. +- Depending on the location of the log destination set in the advanced configuration, the event log can be either found in the application log output or in the database or both. - A sample output of a logged event from application logs would look similar to this: ```JSON @@ -112,7 +112,7 @@ This guide goes into the details of Security Event Logging in Sourcegraph ### What if I don't want these events to be logged? -- To turn off all security event logs, you can [set the variable](/admin/audit-log#excessive-audit-logging) in the site config +- To turn off all security event logs, you can [set the variable](/admin/audit-log#excessive-audit-logging) in the advanced configuration ### How can I correlate the actorID or userID to a user in the application? @@ -120,7 +120,7 @@ This guide goes into the details of Security Event Logging in Sourcegraph 1. Grab the ID from the audit log 1. Base64 [encode](https://www.base64encode.org) the ID with a "User:" prefix. For example, for Actor with ID 71 use `User:71`, which encodes to `VXNlcjo3MQ==` - 1. Navigate to Site Admin -> API Console and run the query below + 1. Navigate to Administration -> API Console and run the query below 1. Find the corresponding user by searching the query results for the encoded ID from above GraphQL query: diff --git a/docs/admin/service-accounts.mdx b/docs/admin/service-accounts.mdx index 919794d13..5c8f73fd9 100644 --- a/docs/admin/service-accounts.mdx +++ b/docs/admin/service-accounts.mdx @@ -19,7 +19,7 @@ If your integration should act as one non-human identity, use a service account. Service accounts are created like regular user accounts, but with a few key differences. -- Go to **Site admin** → **Users & auth** → **Users** +- Go to **Administration** → **Users & auth** → **Users** - Click **Create User** - Enter a descriptive **Username** (e.g., `ci-bot-scip-uploads`, `api-search-jobs`) - Check the **Service account** checkbox @@ -41,7 +41,7 @@ Service accounts can authenticate using either traditional access tokens or M2M M2M credentials are not the same thing as OAuth Apps created in - **Site admin > OAuth clients**. OAuth Apps are for flows where an application + **Administration > OAuth clients**. OAuth Apps are for flows where an application acts on behalf of a user. M2M credentials are separate OAuth clients that are bound to a service account and are the only way to use `grant_type=client_credentials`. diff --git a/docs/admin/subscriptions.mdx b/docs/admin/subscriptions.mdx index 8cebd1d0f..4a3ed2018 100644 --- a/docs/admin/subscriptions.mdx +++ b/docs/admin/subscriptions.mdx @@ -16,13 +16,13 @@ You can [contact Sourcegraph](https://about.sourcegraph.com/contact/sales) to pu ## How user accounts are counted -This count is maintained on your Sourcegraph instance, viewable and auditable on the **Site admin > Users** page, and is reported back in aggregate to Sourcegraph.com via [pings](/admin/pings). +This count is maintained on your Sourcegraph instance, viewable and auditable on the **Administration > Users** page, and is reported back in aggregate to Sourcegraph.com via [pings](/admin/pings). -A Sourcegraph user account is created when a user signs up or signs in for the first time. Sourcegraph user accounts can be deleted by administrators via the **Site admin > Users** page, or using the [GraphQL API](/api/graphql/) or the [Sourcegraph CLI](https://github.com/sourcegraph/src-cli). +A Sourcegraph user account is created when a user signs up or signs in for the first time. Sourcegraph user accounts can be deleted by administrators via the **Administration > Users** page, or using the [GraphQL API](/api/graphql/) or the [Sourcegraph CLI](https://github.com/sourcegraph/src-cli). ## How lines of code are counted -We count the number of newlines (`\n`) appearing in the text search index. Our text search index contains the working copy of your default branch in all repositories synchronized by Sourcegraph. The default branch is typically called `master` or `main`. Additional branches can be configured to be indexed by site administrators. These will also be part of the newlines count. +We count the number of newlines (`\n`) appearing in the text search index. Our text search index contains the working copy of your default branch in all repositories synchronized by Sourcegraph. The default branch is typically called `master` or `main`. Additional branches can be configured to be indexed by administrators. These will also be part of the newlines count. Our text search index deduplicates for paths that are the same across branches. We only count the newlines once per unique file. Forks are separately indexed. They are included in the count of new lines. @@ -30,5 +30,5 @@ Sourcegraph administrators can view the lines of code count for each repository ## Updating your license key -- Navigate to **Site admin > Configuration > Site configuration**, update the `licenseKey` field with the new value, and then click **Save changes**. +- Navigate to **Administration > Configuration > Advanced configuration**, update the `licenseKey` field with the new value, and then click **Save changes**. - Note: once you apply the license it may take 10-15 minutes for the change to take effect. You can always restart the front-end service to apply the change faster, if needed. diff --git a/docs/admin/user-data-deletion.mdx b/docs/admin/user-data-deletion.mdx index 214c6d7ba..6d0cef943 100644 --- a/docs/admin/user-data-deletion.mdx +++ b/docs/admin/user-data-deletion.mdx @@ -1,6 +1,6 @@ # User data deletion -As a site administrator, you have the ability to delete users and their associated data on the **Admin** -> **Users** page (`https://sourcegraph.example.com/site-admin/users`). +As an administrator, you have the ability to delete users and their associated data on the **Administration** -> **Users** page (`https://sourcegraph.example.com/site-admin/users`). On this page, you are presented two options: @@ -15,7 +15,7 @@ When deleting a user with either option, the following information is removed: - User, Organization, or Global settings authored or modified by the user. - Bulk operations on changesets and batch changes created by the user. -> WARNING: If deleted and recreated a user will no longer have access to the configurations and customizations they may have made for their old account. The database will store information about their previous configuration, but a user associated with a new `id` in the `users` table in PostgreSQL will be created. For example, site admin privileges will have to be re-assigned if a once site admin user is deleted and recreated. +> WARNING: If deleted and recreated a user will no longer have access to the configurations and customizations they may have made for their old account. The database will store information about their previous configuration, but a user associated with a new `id` in the `users` table in PostgreSQL will be created. For example, administrator privileges will have to be re-assigned if a once administrator user is deleted and recreated. ## Entities deletion diff --git a/docs/admin/user-surveys.mdx b/docs/admin/user-surveys.mdx index 40bd91f99..a9c2609ce 100644 --- a/docs/admin/user-surveys.mdx +++ b/docs/admin/user-surveys.mdx @@ -1,6 +1,6 @@ # User surveys -Sourcegraph periodically surveys users for feedback. The results are visible to site admins and Sourcegraph. The survey questions are: +Sourcegraph periodically surveys users for feedback. The results are visible to administrators and Sourcegraph. The survey questions are: - How likely is it that you would recommend Sourcegraph to a friend? - What do you use Sourcegraph for? @@ -15,7 +15,7 @@ A user can also visit `https://sourcegraph.example.com/survey` to submit survey ## View survey responses -Responses to this survey are visible to all site admins on the Sourcegraph instance. View all responses on the **Site admin > User surveys** page. (The URL is `https://sourcegraph.example.com/site-admin/surveys`.) +Responses to this survey are visible to all administrators on the Sourcegraph instance. View all responses on the **Administration > User surveys** page. (The URL is `https://sourcegraph.example.com/site-admin/surveys`.) On this page, admins can view individual satisfaction scores (from 0–10) and individual qualitative feedback, along with aggregate historical scores. diff --git a/docs/admin/webhooks/incoming.mdx b/docs/admin/webhooks/incoming.mdx index b85777fd6..10e00d70b 100644 --- a/docs/admin/webhooks/incoming.mdx +++ b/docs/admin/webhooks/incoming.mdx @@ -37,7 +37,7 @@ Before adding an incoming webhook you should ensure that you have at least one [ The incoming webhook will be configured to accept events from a specific code host based on its type and URN. -1. Navigate to **Site Admin > Integrations > Incoming webhooks** +1. Navigate to **Administration > Integrations > Incoming webhooks** ![Incoming webhooks page](https://storage.googleapis.com/sourcegraph-assets/docs/images/administration/config/webhooks/incoming-webhooks-page.png) 2. Click **+ Create webhook** ![Adding an incoming webhook](https://storage.googleapis.com/sourcegraph-assets/docs/images/administration/config/webhooks/adding-webhook.png) @@ -270,16 +270,16 @@ Done! Sourcegraph will now receive webhook events to sync data with lower latenc Sourcegraph can track incoming webhooks from code hosts to more easily debug issues with webhook delivery. These webhooks can be viewed in two places depending on how they were added: -1. Via **Site Admin > Configuration > Incoming webhooks** +1. Via **Administration > Configuration > Incoming webhooks** ![Webhook logs](https://storage.googleapis.com/sourcegraph-assets/docs/images/administration/config/webhooks/webhook-logs.png) -2. **Deprecated** Via code host connection: **Site Admin > Batch Changes > Incoming webhooks** +2. **Deprecated** Via code host connection: **Administration > Batch Changes > Incoming webhooks** ![Legacy webhook logs](https://storage.googleapis.com/sourcegraph-assets/docs/images/administration/config/webhooks/webhook-logs-legacy.png) By default, sites without [database encryption](/self-hosted/encryption) enabled will retain three days of webhook logs. Sites with encryption will not retain webhook logs by default, as webhooks may include sensitive information; these sites can enable webhook logging and optionally configure encryption for them by using the settings below. ### Enabling webhook logging -Webhook logging is controlled by the `webhook.logging` site configuration +Webhook logging is controlled by the `webhook.logging` advanced configuration option. This option is an object with the following keys: | Key | Type | Default | Description | @@ -310,4 +310,4 @@ To retain webhook logs for one day: ### Encrypting webhook logs -Webhook logs can be encrypted by specifying a `webhookLogKey` in the [on-disk database encryption site configuration](/self-hosted/encryption). +Webhook logs can be encrypted by specifying a `webhookLogKey` in the [on-disk database encryption advanced configuration](/self-hosted/encryption). diff --git a/docs/admin/webhooks/outgoing.mdx b/docs/admin/webhooks/outgoing.mdx index 740c3952e..90afc00b5 100644 --- a/docs/admin/webhooks/outgoing.mdx +++ b/docs/admin/webhooks/outgoing.mdx @@ -8,7 +8,7 @@ Currently, outgoing webhooks cannot yet be scoped to specific entities, meaning ## Adding an outgoing webhook -1. Navigate to **Site Admin > Configuration > Outgoing webhooks** +1. Navigate to **Administration > Configuration > Outgoing webhooks** ![Outgoing webhooks page](https://storage.googleapis.com/sourcegraph-assets/docs/images/administration/config/webhooks/outgoing-webhooks-page.png) 1. Click **+ Create webhook** ![Adding an outgoing webhook](https://storage.googleapis.com/sourcegraph-assets/docs/images/administration/config/webhooks/adding-outgoing-webhook.png) diff --git a/docs/agentic-batch-changes/configuration.mdx b/docs/agentic-batch-changes/configuration.mdx index 7120adf03..2cb815db6 100644 --- a/docs/agentic-batch-changes/configuration.mdx +++ b/docs/agentic-batch-changes/configuration.mdx @@ -4,7 +4,7 @@ The agent discovers a lot on its own through Deep Search: which package manager a repository uses, how CI is wired, and where similar migrations have been done before. But internal policies may not be written in the code: which base images you allow, how you name branches, which approvals a dependency bump needs, or what a good commit message looks like in your organization. -You can add guidance on the **Agents** page of your Batch Changes settings, at `sourcegraph.example.com/users//settings/batch-changes/agents`. Site administrators add instance-wide guidance at `sourcegraph.example.com/admin/batch-changes/agents`, and organizations can carry shared guidance in their settings. Entries from all three levels combine. +You can add guidance on the **Agents** page of your Batch Changes settings, at `sourcegraph.example.com/users//settings/batch-changes/agents`. Administrators add instance-wide guidance at `sourcegraph.example.com/admin/batch-changes/agents`, and organizations can carry shared guidance in their settings. Entries from all three levels combine. ### Guidance and skills @@ -83,7 +83,7 @@ When a new or changed step uses a secret, the agent shows you that step and wait Some steps need credentials: a package registry token for private dependencies or an API key for reading CI logs. These are managed on two settings pages: - Your own secrets live under **Secrets** in your Batch Changes settings, at `/users//settings/batch-changes/secrets`. -- Site administrators manage global secrets, available to every user, at `/admin/batch-changes/secrets`. +- Administrators manage global secrets, available to every user, at `/admin/batch-changes/secrets`. Your own secret takes precedence over a global one with the same name. @@ -134,7 +134,7 @@ All code-modifying work runs on executors: ### Usage limits -Coding agent runs are metered per user through the **Batch Changes coding agent step runs** [entitlement](/admin/entitlements), managed under **Site admin → Users & auth → Entitlements**. Each coding agent run in a repository consumes one unit. A default entitlement applies to every user, and an explicit grant replaces the default for a specific user: +Coding agent runs are metered per user through the **Batch Changes coding agent step runs** [entitlement](/admin/entitlements), managed under **Administration → Users & auth → Entitlements**. Each coding agent run in a repository consumes one unit. A default entitlement applies to every user, and an explicit grant replaces the default for a specific user: - Users without an entitlement have unlimited usage. - A positive limit blocks further runs once reached until its window resets. @@ -161,16 +161,16 @@ You can shape this behavior with [guidance](#guidance-and-skills) if your team w ### Web search -Web search is enabled by default for the coordinating agent and its coding agents. To disable it for both, set `batchChanges.disableAgentWebSearch` to `true` in [site configuration](/admin/config/site-config). +Web search is enabled by default for the coordinating agent and its coding agents. To disable it for both, set `batchChanges.disableAgentWebSearch` to `true` in [advanced configuration](/admin/config/site-config). This setting disables web search tools. It does not block outbound network access from executor containers, including commands run by scripts or coding agents. Restrict that access separately through your executor network policy. ### Images -Steps run in container images the agent picks, preferring small public images that already carry the needed tools. You can restrict where images come from with `batchChanges.containerRegistryAllowlist` or `batchChanges.containerRegistryDenylist` in site configuration; the two are mutually exclusive, and an empty list allows every registry. +Steps run in container images the agent picks, preferring small public images that already carry the needed tools. You can restrict where images come from with `batchChanges.containerRegistryAllowlist` or `batchChanges.containerRegistryDenylist` in advanced configuration; the two are mutually exclusive, and an empty list allows every registry. When no public image fits, the agent can build one on the fly and reuse it across the batch change. Custom-built images are hosted directly in Sourcegraph. Image building is available on Sourcegraph Cloud by default and requires additional setup on self-hosted instances. ### Pull request attribution -Agentic Batch Changes link generated changesets back to their agent conversation in both the changeset description and commit message by default. Site administrators can [configure pull request attribution](/admin/config/batch-changes#pull-request-attribution) to keep this link out of descriptions that may trigger unwanted code host notifications. +Agentic Batch Changes link generated changesets back to their agent conversation in both the changeset description and commit message by default. Administrators can [configure pull request attribution](/admin/config/batch-changes#pull-request-attribution) to keep this link out of descriptions that may trigger unwanted code host notifications. diff --git a/docs/analytics/api.mdx b/docs/analytics/api.mdx index 83f59a0e4..3e3be950b 100644 --- a/docs/analytics/api.mdx +++ b/docs/analytics/api.mdx @@ -65,7 +65,7 @@ The export contains the following columns: - `Instance user ID`: The numeric ID assigned to the user by the Sourcegraph instance. - `Service Account`: Whether the user is a service account (`true` or `false`). -- `Site Admin`: Whether the user is a site administrator (`true` or `false`). +- `Site Admin`: Whether the user is an administrator (`true` or `false`). To download the user registry: diff --git a/docs/api/graphql/index.mdx b/docs/api/graphql/index.mdx index fa1e3c262..26fac974a 100644 --- a/docs/api/graphql/index.mdx +++ b/docs/api/graphql/index.mdx @@ -78,7 +78,7 @@ console page. ### Sudo access tokens -Site admins may create access tokens with the special `site-admin:sudo` scope, which allows the holder to perform any action as any other user. +Administrators may create access tokens with the special `site-admin:sudo` scope, which allows the holder to perform any action as any other user. ```bash curl -H 'Authorization: token-sudo user="SUDO_TO_USERNAME",token="YOUR_TOKEN"' @@ -113,7 +113,7 @@ i.e. you just need to send the `Authorization` header and a JSON object like `{" ## Cost Limits -To ensure system performance and stability, configurable GraphQL query cost limitations have been implemented. This feature is crucial for preventing resource exhaustion due to extensive or overly complex queries. The default configuration looks as follows, and can be modified in site configuration: +To ensure system performance and stability, configurable GraphQL query cost limitations have been implemented. This feature is crucial for preventing resource exhaustion due to extensive or overly complex queries. The default configuration looks as follows, and can be modified in advanced configuration: ``` "rateLimits": { diff --git a/docs/api/mcp/authentication.mdx b/docs/api/mcp/authentication.mdx index fc222fff0..741399b1d 100644 --- a/docs/api/mcp/authentication.mdx +++ b/docs/api/mcp/authentication.mdx @@ -30,7 +30,7 @@ Configure and test pre-registered clients before disabling DCR to avoid interrup ### Create an OAuth Client -1. In Sourcegraph, navigate to **Site admin > OAuth clients**. +1. In Sourcegraph, navigate to **Administration > OAuth clients**. 2. Click **Create OAuth client** and configure it with: - A descriptive name and optional description. - The redirect URI required by your MCP client. For `mcp-remote`, use `http://localhost:3334/oauth/callback`. diff --git a/docs/api/mcp/index.mdx b/docs/api/mcp/index.mdx index b944393fb..580cea62c 100644 --- a/docs/api/mcp/index.mdx +++ b/docs/api/mcp/index.mdx @@ -45,14 +45,14 @@ See [MCP Authentication](/api/mcp/authentication) to choose and configure an aut Admins can control MCP at three levels: -- Site configuration: `mcp.enabled` enables or disables the MCP HTTP endpoints. +- Advanced configuration: `mcp.enabled` enables or disables the MCP HTTP endpoints. - Tool-level configuration: `mcp.tools.disabled` disables individual MCP tools by name. - OAuth Dynamic Client Registration: `auth.idpDynamicClientRegistrationEnabled` controls whether OAuth clients can self-register. See [MCP Authentication](/api/mcp/authentication#disable-dynamic-client-registration) to disable DCR and configure pre-registered clients. - RBAC: users must have the `MCP#ACCESS` permission to use MCP. ### Site-Level Enablement -Use the `mcp.enabled` site configuration to turn the MCP server on or off for the entire instance: +Use the `mcp.enabled` advanced configuration to turn the MCP server on or off for the entire instance: ```json { @@ -65,7 +65,7 @@ and its subpaths return `404 no route`. ### Disabling Individual Tools -Use the `mcp.tools.disabled` site configuration setting to remove specific tools +Use the `mcp.tools.disabled` advanced configuration setting to remove specific tools from all MCP endpoints while keeping the rest of the server available. The setting takes an array of strings, where each string is the name of a tool to disable - e.g. `code_finder` or `deepsearch`: @@ -91,7 +91,7 @@ permissions. To restrict MCP to a subset of users: -1. Open **Site admin > Users & auth > Roles**. +1. Open **Administration > Users & auth > Roles**. 2. Edit the built-in **User** role and remove the `MCP > ACCESS` permission if you want MCP denied by default. 3. Create a custom role that includes `MCP > ACCESS`. 4. Assign that role to the users who should be allowed to use MCP. diff --git a/docs/batch-changes/batch-spec-yaml-reference.mdx b/docs/batch-changes/batch-spec-yaml-reference.mdx index 61ce5a820..3dc353bb7 100644 --- a/docs/batch-changes/batch-spec-yaml-reference.mdx +++ b/docs/batch-changes/batch-spec-yaml-reference.mdx @@ -760,7 +760,7 @@ changesetTemplate: Whether or not each changeset should be created on a fork of the upstream repository in the namespace of the user publishing them (or the namespace of the service account if [global credentials](/batch-changes/configuring-credentials#global-service-account-tokens) are used). -This value will override the setting if the site config setting [`batchChanges.enforceForks`](/admin/config/batch-changes#forks) is enabled. For example, explicitly setting `fork: false` when the site config setting is enabled will publish changesets directly to the target repos. If omitted, the site config setting will be used. +This value will override the setting if the advanced configuration setting [`batchChanges.enforceForks`](/admin/config/batch-changes#forks) is enabled. For example, explicitly setting `fork: false` when the advanced configuration setting is enabled will publish changesets directly to the target repos. If omitted, the advanced configuration setting will be used. The name of the fork Sourcegraph creates will be prefixed with the name of the original repo's namespace to prevent potential repo name collisions. For example, a batch spec targeting `github.com/my-org/project` would create or use any existing fork named `github.com/user/my-org-project`. diff --git a/docs/batch-changes/configuring-credentials.mdx b/docs/batch-changes/configuring-credentials.mdx index 31a6e9b03..a9ccea9de 100644 --- a/docs/batch-changes/configuring-credentials.mdx +++ b/docs/batch-changes/configuring-credentials.mdx @@ -114,10 +114,10 @@ If [forks are enabled](/admin/config/batch-changes#forks), then note that reposi ### Adding a global service token -Adding a global service account token is done through the Batch Changes section of the site admin area: +Adding a global service account token is done through the Batch Changes section of the Administration area: - From any Sourcegraph page, click on your avatar at the top right of the page -- Select **Site admin** from the dropdown menu +- Select **Administration** from the dropdown menu - Click **Settings** under the **Batch Changes** sub-heading on the sidebar menu - Click **Add credentials** and follow the steps to [create a new token](#creating-a-code-host-token) for the code host. If the code host is GitHub, select **Personal Access Token** as the **Authentication strategy**. @@ -125,7 +125,7 @@ Code hosts with tokens configured are indicated by a green tick to the left of t ### Removing a global service token -To remove a token, navigate to the same section of the site admin area, then click **Remove**. Once the token is removed, the code host's indicator should revert to the empty red circle. +To remove a token, navigate to the same section of the Administration area, then click **Remove**. Once the token is removed, the code host's indicator should revert to the empty red circle. ## Creating a code host token @@ -379,7 +379,7 @@ If you want to delete the GitHub app entirely, you have to navigate to [GitHub's Sourcegraph supports OAuth-based authentication for Batch Changes with both Bitbucket Server (Data Center) and Bitbucket Cloud. This allows users to authorize Batch Changes to act on their behalf using OAuth instead of manually creating personal access tokens or app passwords. - Bitbucket OAuth for Batch Changes requires a site administrator to first configure a Bitbucket + Bitbucket OAuth for Batch Changes requires an administrator to first configure a Bitbucket [authentication provider](/admin/auth) in Sourcegraph. The same auth provider used for SSO sign-in is reused for Batch Changes — no additional provider configuration is needed. @@ -388,7 +388,7 @@ Sourcegraph supports OAuth-based authentication for Batch Changes with both Bitb #### Prerequisites -A Sourcegraph site administrator must configure a [Bitbucket Server authentication provider](/admin/auth#bitbucket-server). If your instance already uses Bitbucket Server for sign-in, this step is already complete. +A Sourcegraph administrator must configure a [Bitbucket Server authentication provider](/admin/auth#bitbucket-server). If your instance already uses Bitbucket Server for sign-in, this step is already complete. The OAuth consumer in Bitbucket Server should be configured as an incoming application link with at minimum **Read** permission on **Repositories**. When a user initiates the Batch Changes OAuth flow, Sourcegraph automatically requests the elevated scopes needed: @@ -412,7 +412,7 @@ You can migrate from personal access tokens to OAuth by deleting the existing PA #### Prerequisites -A Sourcegraph site administrator must configure a [Bitbucket Cloud authentication provider](/admin/auth#bitbucket-cloud). If your instance already uses Bitbucket Cloud for sign-in, this step is already complete. +A Sourcegraph administrator must configure a [Bitbucket Cloud authentication provider](/admin/auth#bitbucket-cloud). If your instance already uses Bitbucket Cloud for sign-in, this step is already complete. The OAuth consumer in Bitbucket Cloud should have the following permissions enabled: @@ -452,7 +452,7 @@ You can migrate from app passwords to OAuth by deleting the existing credential OAuth tokens have limited lifetimes. Sourcegraph automatically refreshes tokens when they expire using the refresh token obtained during authorization. Token refresh is handled transparently — users do not need to re-authorize unless the refresh token itself is revoked or the OAuth consumer is deleted. - The Bitbucket authentication provider must remain configured in the Sourcegraph site configuration + The Bitbucket authentication provider must remain configured in the Sourcegraph advanced configuration for token refresh to work. If the auth provider is removed, tokens will not be refreshed and will eventually expire. diff --git a/docs/batch-changes/create-a-batch-change.mdx b/docs/batch-changes/create-a-batch-change.mdx index 0080cf2cb..327263a37 100644 --- a/docs/batch-changes/create-a-batch-change.mdx +++ b/docs/batch-changes/create-a-batch-change.mdx @@ -34,7 +34,7 @@ From the template selection page, you can either: ![templates_list](https://sourcegraphstatic.com/docs/images/batch_changes/2025/templates_list.png) -Your site admin can curate the list of available templates to match your organization's specific needs and use cases. +Your administrator can curate the list of available templates to match your organization's specific needs and use cases. ### Filling out template fields @@ -58,7 +58,7 @@ You can now see the batch spec and run a preview of the affected repositories an Batch Changes can also be used on [multiple projects within a monorepo](/batch-changes/creating-changesets-per-project-in-monorepos) by using the `workspaces` key in your batch spec. -The library contains examples that you can apply right into your batch spec if you need inspiration. Your site admin can manage the library of examples. +The library contains examples that you can apply right into your batch spec if you need inspiration. Your administrator can manage the library of examples. ![ssbc_workspace_preview](https://sourcegraphstatic.com/docs/images/batch_changes/2024/ssbc_workspace_preview.png) diff --git a/docs/batch-changes/permissions-in-batch-changes.mdx b/docs/batch-changes/permissions-in-batch-changes.mdx index de26b3b28..dd08c6fdf 100644 --- a/docs/batch-changes/permissions-in-batch-changes.mdx +++ b/docs/batch-changes/permissions-in-batch-changes.mdx @@ -20,7 +20,7 @@ To see the batch change's proposed changes on a repository, a user requires **re Changes](#repository-permissions-for-batch-changes). -Site admins have admin permissions on all batch changes. However, other users can only have admin permissions on the batch changes they created and read access to other batch changes. +Administrators have admin permissions on all batch changes. However, other users can only have admin permissions on the batch changes they created and read access to other batch changes. These levels apply on top of [role-based access control](/admin/access-control/batch-changes): a user needs the `batch_changes:read` permission to view any batch change and the `batch_changes:write` permission to create or execute one. See [Restricting Batch Changes to specific users](#restricting-batch-changes-to-specific-users). @@ -86,24 +86,26 @@ If you are not permitted to view a repository on Sourcegraph, you won't be able ## Disabling Batch Changes -A site admin can disable Batch Changes for a Sourcegraph instance by setting the [site configuration](/admin/config/site-config) property `"batchChanges.enabled"` to `false`. +An administrator can disable Batch Changes for a Sourcegraph instance by setting the [advanced configuration](/admin/config/site-config) property `"batchChanges.enabled"` to `false`. ## Restricting Batch Changes to specific users Access to Batch Changes is controlled through [role-based access control (RBAC)](/admin/access-control/batch-changes). By default, the built-in **User** role is granted both the `batch_changes:read` and `batch_changes:write` permissions, so every user can view, create, and run batch changes. -To restrict Batch Changes to site admins or to a specific group of users: +To restrict Batch Changes to administrators or to a specific group of users: -1. Go to **Site admin > Users & auth > Roles**. +1. Go to **Administration > Users & auth > Roles**. 2. Edit the **User** role and remove the `batch_changes:read` and `batch_changes:write` permissions. 3. Optionally, [create a custom role](/admin/access-control#creating-a-new-role-and-assigning-it-permissions) that grants these permissions and [assign it](/admin/access-control#managing-user-roles) to the users who should keep access. -The **Site Administrator** role always retains all Batch Changes permissions. +The **Administrator** role always retains all Batch Changes permissions. - The site configuration property `"batchChanges.restrictToAdmins"` is deprecated and has no effect. Use RBAC as described above instead. + The advanced configuration property `"batchChanges.restrictToAdmins"` is deprecated and has no effect. Use RBAC as described above instead. -## Restricting merges to site admins + -A site admin can prevent non-admin users from merging changesets or enabling auto-merge through Batch Changes by setting the [site configuration](/admin/config/site-config) property `"batchChanges.restrictMergeToAdmins"` to `true`. This is useful when the code host credential or GitHub App used by Batch Changes has broader merge permissions than individual users would otherwise have. All other Batch Changes operations remain governed by RBAC and the permission levels described above. +## Restricting merges to administrators + +An administrator can prevent non-admin users from merging changesets or enabling auto-merge through Batch Changes by setting the [advanced configuration](/admin/config/site-config) property `"batchChanges.restrictMergeToAdmins"` to `true`. This is useful when the code host credential or GitHub App used by Batch Changes has broader merge permissions than individual users would otherwise have. All other Batch Changes operations remain governed by RBAC and the permission levels described above. diff --git a/docs/batch-changes/requirements.mdx b/docs/batch-changes/requirements.mdx index 8b2e711d6..af60cf360 100644 --- a/docs/batch-changes/requirements.mdx +++ b/docs/batch-changes/requirements.mdx @@ -47,7 +47,7 @@ It's **highly recommended** to enable the webhooks on code hosts where batch cha - [Bitbucket/Bitbucket Data Center](/admin/code-hosts/bitbucket-server#webhooks) - [GitLab](/admin/code-hosts/gitlab#webhooks) -If you are unable to enable webhooks, you can disable the warning Sourcegraph displays when viewing batch changes by setting the `batchChanges.disableWebhooksWarning` [site configuration setting](/admin/config/site-config) to `true`. +If you are unable to enable webhooks, you can disable the warning Sourcegraph displays when viewing batch changes by setting the `batchChanges.disableWebhooksWarning` [advanced configuration setting](/admin/config/site-config) to `true`. ### Batch Changes effect on CI systems diff --git a/docs/batch-changes/server-side.mdx b/docs/batch-changes/server-side.mdx index c301fa1d8..3e1274d3c 100644 --- a/docs/batch-changes/server-side.mdx +++ b/docs/batch-changes/server-side.mdx @@ -23,7 +23,7 @@ This allows to: Sourcegraph Cloud includes Sourcegraph-managed executors by default, so Cloud customers using them do not need to deploy executor infrastructure. -If you operate a self-hosted Sourcegraph instance, [deploy executors](/self-hosted/executors) and confirm that they are online. This is a one-time process. Once a site administrator sets up executors and enables running Batch Changes server-side, users can get started without additional executor setup. +If you operate a self-hosted Sourcegraph instance, [deploy executors](/self-hosted/executors) and confirm that they are online. This is a one-time process. Once an administrator sets up executors and enables running Batch Changes server-side, users can get started without additional executor setup. ## Limitations diff --git a/docs/batch-changes/site-admin-configuration.mdx b/docs/batch-changes/site-admin-configuration.mdx index d0dfa3a6b..060af67c7 100644 --- a/docs/batch-changes/site-admin-configuration.mdx +++ b/docs/batch-changes/site-admin-configuration.mdx @@ -1,14 +1,14 @@ -# Site Admin Configuration for Batch Changes +# Administrator Configuration for Batch Changes

- Learn what configuration permissions site admins have with Batch Changes. + Learn what configuration permissions administrators have with Batch Changes.

-Using Batch Changes requires a [code host connection](/admin/code-hosts/) to a supported code host (currently GitHub, Bitbucket Server/Bitbucket Data Center, GitLab, and Bitbucket Cloud). Site admins can configure the following when setting and disabling Batch Changes: +Using Batch Changes requires a [code host connection](/admin/code-hosts/) to a supported code host (currently GitHub, Bitbucket Server/Bitbucket Data Center, GitLab, and Bitbucket Cloud). Administrators can configure the following when setting and disabling Batch Changes: ## Set up Batch Changes -- [Configure which users have access to Batch Changes](/admin/access-control/batch-changes): By default, all users can create and view batch changes, but only the batch change's author or a site admin can administer a given batch change +- [Configure which users have access to Batch Changes](/admin/access-control/batch-changes): By default, all users can create and view batch changes, but only the batch change's author or an administrator can administer a given batch change - Additionally, you can also [customize org settings](/admin/config/batch-changes#enable-organization-members-to-administer) to allow members of an organization to share administration privileges over batch changes created in that organization - (Optional) [Configure repository permissions](/admin/permissions/), that Batch Changes will follow - [Configure credentials](/batch-changes/configuring-credentials) @@ -26,4 +26,4 @@ Using Batch Changes requires a [code host connection](/admin/code-hosts/) to a s - [Disable Batch Changes](/batch-changes/permissions-in-batch-changes#disabling-batch-changes). - [Restrict Batch Changes to specific users](/batch-changes/permissions-in-batch-changes#restricting-batch-changes-to-specific-users) using [role-based access control](/admin/access-control/batch-changes) -- [Restrict merging changesets to site admins](/batch-changes/permissions-in-batch-changes#restricting-merges-to-site-admins) +- [Restrict merging changesets to administrators](/batch-changes/permissions-in-batch-changes#restricting-merges-to-site-admins) diff --git a/docs/batch-changes/view-batch-changes.mdx b/docs/batch-changes/view-batch-changes.mdx index fcee72275..e4bbb4307 100644 --- a/docs/batch-changes/view-batch-changes.mdx +++ b/docs/batch-changes/view-batch-changes.mdx @@ -32,4 +32,4 @@ When looking at a batch change, you can search and filter the list of changesets ## Administration -Once a batch change is open, any Sourcegraph user can view it. However, the namespace determines who can administer it, such as editing or deleting it. When a batch change is created in a user namespace, only that user (and site admins) can administer it. When a batch change is created in an organization namespace, all members of that organization (and site admins) can administer it. +Once a batch change is open, any Sourcegraph user can view it. However, the namespace determines who can administer it, such as editing or deleting it. When a batch change is created in a user namespace, only that user (and administrators) can administer it. When a batch change is created in an organization namespace, all members of that organization (and administrators) can administer it. diff --git a/docs/cli/explanations/env.mdx b/docs/cli/explanations/env.mdx index c39917d8c..65f7cd512 100644 --- a/docs/cli/explanations/env.mdx +++ b/docs/cli/explanations/env.mdx @@ -17,7 +17,7 @@ Use OAuth for local interactive use, or set the environment variables below for https://sourcegraph.com ``` -If you're unsure what the URL for your Sourcegraph instance is, please contact your site administrator. +If you're unsure what the URL for your Sourcegraph instance is, please contact your administrator. If the environment variable is not set, it'll default to "https://sourcegraph.com" diff --git a/docs/cli/how-tos/managing-access-tokens.mdx b/docs/cli/how-tos/managing-access-tokens.mdx index 137759974..0da79accc 100644 --- a/docs/cli/how-tos/managing-access-tokens.mdx +++ b/docs/cli/how-tos/managing-access-tokens.mdx @@ -1,6 +1,6 @@ # Managing access tokens -The `auth.accessTokens` setting in Sourcegraph's site configuration allows admins to fine-tune parameters related to access tokens: +The `auth.accessTokens` setting in Sourcegraph's advanced configuration allows admins to fine-tune parameters related to access tokens: ```json { diff --git a/docs/cloud/index.mdx b/docs/cloud/index.mdx index 7448d9bda..9b7890f66 100644 --- a/docs/cloud/index.mdx +++ b/docs/cloud/index.mdx @@ -156,7 +156,7 @@ All Sourcegraph Cloud instances are provisioned with a Sourcegraph-managed SMTP By default, emails will be sent from an `@cloud.sourcegraph.com` email address. To test email delivery, refer to [sending a test email](/self-hosted/email#sending-a-test-email). -To opt out of managed SMTP, please let your Sourcegraph Account team know when requesting a trial. You can also opt out by [overriding the managed `email.address` and `email.smtp` configuration with your own in site configuration](/self-hosted/email). If you have specific requests for managed SMTP, please [reach out regarding special requirements](#accommodating-special-requirements). +To opt out of managed SMTP, please let your Sourcegraph Account team know when requesting a trial. You can also opt out by [overriding the managed `email.address` and `email.smtp` configuration with your own in advanced configuration](/self-hosted/email). If you have specific requests for managed SMTP, please [reach out regarding special requirements](#accommodating-special-requirements). To learn more about how the Sourcegraph team operates managed SMTP internally, refer to [our handbook](https://handbook.sourcegraph.com/departments/cloud/technical-docs/managed-smtp/). diff --git a/docs/cloud/private-connectivity-aws.mdx b/docs/cloud/private-connectivity-aws.mdx index d12f58665..9d5f425b8 100644 --- a/docs/cloud/private-connectivity-aws.mdx +++ b/docs/cloud/private-connectivity-aws.mdx @@ -89,7 +89,7 @@ Only if the private artifact registry is protected by authentication, the custom ### Can I use self-signed TLS certificate for my private resources? -Yes. Please work with your account team to add the certificate chain of your internal CA to [site configuration](/admin/config/site-config) at `tls.external.certificates`. +Yes. Please work with your account team to add the certificate chain of your internal CA to [advanced configuration](/admin/config/site-config) at `tls.external.certificates`. ### What is the disaster recovery plan? diff --git a/docs/cloud/private-connectivity-gcp.mdx b/docs/cloud/private-connectivity-gcp.mdx index 4c588a7b0..a936b66ca 100644 --- a/docs/cloud/private-connectivity-gcp.mdx +++ b/docs/cloud/private-connectivity-gcp.mdx @@ -85,4 +85,4 @@ Only if the private artifact registry is protected by authentication, the custom ### Can I use self-signed TLS certificate for my private resources? -Yes. Please work with your account team to add the certificate chain of your internal CA to [site configuration](/admin/config/site-config) at `tls.external.certificates`. +Yes. Please work with your account team to add the certificate chain of your internal CA to [advanced configuration](/admin/config/site-config) at `tls.external.certificates`. diff --git a/docs/cloud/private-connectivity-public-lb.mdx b/docs/cloud/private-connectivity-public-lb.mdx index 35440fc39..b7282856f 100644 --- a/docs/cloud/private-connectivity-public-lb.mdx +++ b/docs/cloud/private-connectivity-public-lb.mdx @@ -72,4 +72,4 @@ If private artifact registry is protected by authentication, the customer will n ### Can I use self-signed TLS certificate for my private resources? -Yes. Please work with your account team to add the certificate chain of your internal CA to [site configuration](/admin/config/site-config) at `tls.external.certificates`. +Yes. Please work with your account team to add the certificate chain of your internal CA to [advanced configuration](/admin/config/site-config) at `tls.external.certificates`. diff --git a/docs/cloud/private-connectivity-sourcegraph-connect.mdx b/docs/cloud/private-connectivity-sourcegraph-connect.mdx index f20770be4..7ff5efdab 100644 --- a/docs/cloud/private-connectivity-sourcegraph-connect.mdx +++ b/docs/cloud/private-connectivity-sourcegraph-connect.mdx @@ -105,7 +105,7 @@ The tunnel from the agent to the server is encrypted and authenticated by mTLS o ### Can I use Internal PKI or self-signed TLS certificates for my private resources? -Yes. Please work with your account team to add the public certificate chain of your internal CAs, and / or your private resources' self-signed certs, under `tls.external.certificates` in your instance's [site configuration](/admin/config/site-config). +Yes. Please work with your account team to add the public certificate chain of your internal CAs, and / or your private resources' self-signed certs, under `tls.external.certificates` in your instance's [advanced configuration](/admin/config/site-config). ### Is this connection highly available? diff --git a/docs/code-insights/explanations/administration-and-security-of-code-insights.mdx b/docs/code-insights/explanations/administration-and-security-of-code-insights.mdx index 08d2551af..2697985b5 100644 --- a/docs/code-insights/explanations/administration-and-security-of-code-insights.mdx +++ b/docs/code-insights/explanations/administration-and-security-of-code-insights.mdx @@ -33,7 +33,7 @@ If a user gets deleted, any insights they created will still be visible to other ## Code Insights Admin (>=5.0) -Sourcegraph administrators can view and manage the background jobs that Code Insights runs when historically backfilling an insight. The following functionality is available under _Code Insights jobs_ in the _Maintenance_ section within the Site Admin (`/site-admin/code-insights-jobs`): +Sourcegraph administrators can view and manage the background jobs that Code Insights runs when historically backfilling an insight. The following functionality is available under _Code Insights jobs_ in the _Maintenance_ section within Administration (`/site-admin/code-insights-jobs`): - See a list of the jobs that backfill an insight and their current state - See any errors that occurred when backfilling an insight @@ -42,9 +42,11 @@ Sourcegraph administrators can view and manage the background jobs that Code Ins The jobs can be searched by state and by an insight's title or the label of any of its series. -## Code Insights Site Configuration + -While the default configuration is appropriate for most deployments, in the site configuration there are values that allow admins more control over the rate at which insights runs in the background. +## Code Insights Advanced Configuration + +While the default configuration is appropriate for most deployments, in the advanced configuration there are values that allow admins more control over the rate at which insights runs in the background. Raising these values will increase the speed at which insights are populated however will it cause insights to consume more system resources. Care should be taken when changing these values and it is recommended to update them in small increments. diff --git a/docs/code-insights/explanations/current-limitations-of-code-insights.mdx b/docs/code-insights/explanations/current-limitations-of-code-insights.mdx index c2b914089..c800293bc 100644 --- a/docs/code-insights/explanations/current-limitations-of-code-insights.mdx +++ b/docs/code-insights/explanations/current-limitations-of-code-insights.mdx @@ -54,7 +54,7 @@ You can determine if this issue may be affecting your query by just running the In this case, you may want to try: - Using a more granular query -- Changing your site configuration so that the timeout is increased, provided your instance setup allows it. [More information on timeouts](/code-search/queries/language#timeout). +- Changing your advanced configuration so that the timeout is increased, provided your instance setup allows it. [More information on timeouts](/code-search/queries/language#timeout). ## General scale limitations @@ -82,7 +82,7 @@ The reason for that restriction is security concerns around exposing the code in Code Insights exposes only aggregated analytics and counts of patterns, though, not the raw code, so the security concerns could be less for Code Insights. -If desired, a Sourcegraph admin can enable Code Insights access to repositories that use sub-repo permissions in site config: +If desired, a Sourcegraph admin can enable Code Insights access to repositories that use sub-repo permissions in advanced configuration: ```json "experimentalFeatures": { diff --git a/docs/code-insights/explanations/data-retention.mdx b/docs/code-insights/explanations/data-retention.mdx index 8e25443f8..a4af71f98 100644 --- a/docs/code-insights/explanations/data-retention.mdx +++ b/docs/code-insights/explanations/data-retention.mdx @@ -3,7 +3,7 @@ On creation a Code Insight will show you 12 data points per series. Your Code Insight will then get an additional ephemeral data point daily, and a persisted additional data point at every interval that was specified on insight creation. -The oldest data points will be truncated and stored separately according to the sample size specified in the site configuration with the setting shown below. +The oldest data points will be truncated and stored separately according to the sample size specified in the advanced configuration with the setting shown below. This means that if you have an insight with 50 data points, and a maximum sample size of 30, the oldest 20 points will be truncated and archived in a separate table. ```json diff --git a/docs/code-insights/references/incomplete-data-points.mdx b/docs/code-insights/references/incomplete-data-points.mdx index 8c19e7392..1f848436e 100644 --- a/docs/code-insights/references/incomplete-data-points.mdx +++ b/docs/code-insights/references/incomplete-data-points.mdx @@ -136,7 +136,7 @@ To learn more about writing precise queries, see our [search query syntax](/code By default, search queries have a one minute timeout. This value is capped by the setting `search.limits.maxTimeoutSeconds` which by default is also one minute. -Your site admin can change this value to increase the maximum timeout. Once it is increased, you can use the search parameter `timeout:` to give the query more time to run. +Your administrator can change this value to increase the maximum timeout. Once it is increased, you can use the search parameter `timeout:` to give the query more time to run. Example: diff --git a/docs/code-insights/references/requirements.mdx b/docs/code-insights/references/requirements.mdx index 9e104cdd6..c3673adf9 100644 --- a/docs/code-insights/references/requirements.mdx +++ b/docs/code-insights/references/requirements.mdx @@ -17,4 +17,4 @@ You can only use Code Insights on a [Docker Compose](/self-hosted/deploy/docker- Sourcegraph Code Insights is compatible with any [Sourcegraph-compatible code host](/admin/repo/). -If the repo has [sub-repo permissions](/admin/permissions/api#setting-sub-repository-permissions-for-users) configured, an admin will need to set `experimentalSettings.subRepoPermissions.allowCodeInsights` to `true` in site config to allow Code Insights to query that repo. +If the repo has [sub-repo permissions](/admin/permissions/api#setting-sub-repository-permissions-for-users) configured, an admin will need to set `experimentalSettings.subRepoPermissions.allowCodeInsights` to `true` in advanced configuration to allow Code Insights to query that repo. diff --git a/docs/code-insights/types/inventory-stats.mdx b/docs/code-insights/types/inventory-stats.mdx index 420130fad..03a11d641 100644 --- a/docs/code-insights/types/inventory-stats.mdx +++ b/docs/code-insights/types/inventory-stats.mdx @@ -27,14 +27,14 @@ Now, you can perform all the actions you can on other Code Insights, such as edi ## Inventory environment variables - Inventory environment variables have been moved into site configuration. + Inventory environment variables have been moved into advanced configuration. This impacts any self-hosted customer using these environment variables. Cloud customers are not impacted by this change. -If you are a self-hosted Sourcegraph Enterprise user, we have moved the inventory environment variables into the **inventory** section of the **Site configuration** settings in your **Site admin** page. +If you are a self-hosted Sourcegraph Enterprise user, we have moved the inventory environment variables into the **inventory** section of the **Advanced configuration** settings in your **Administration** page. -Here's a list oI the Inventory environment variables and their new site configuration settings, with default values: +Here's a list oI the Inventory environment variables and their new advanced configuration settings, with default values: - `USE_ENHANCED_LANGUAGE_DETECTION` ==> `"disableEnhancedLanguageDetection"` - defaults to `false` @@ -47,7 +47,7 @@ Here's a list oI the Inventory environment variables and their new site configur - `GET_INVENTORY_TIMEOUT` ==> `"timeoutInMinutes"` - defaults to `5` -Here's an example of the site configuration section: +Here's an example of the advanced configuration section: ```json "inventory" : { @@ -60,7 +60,7 @@ Here's an example of the site configuration section: ``` - To accommodate default values in your Site configuration vs. environment + To accommodate default values in your Advanced configuration vs. environment variables, the positive `USE_ENHANCED_LANGUAGE_DETECTION` env var has been changed to the negative `disableEnhancedLanguageDetection`. diff --git a/docs/code-monitoring/index.mdx b/docs/code-monitoring/index.mdx index 9e98b3d4d..f21291fbe 100644 --- a/docs/code-monitoring/index.mdx +++ b/docs/code-monitoring/index.mdx @@ -57,7 +57,7 @@ An _action_ is executed in response to a trigger event. Currently, code monitori ### Sending a notification email to the owner of the code monitor -Prerequisite: Ensure [email notifications](/self-hosted/observability/alerting#email) are configured in site configuration. +Prerequisite: Ensure [email notifications](/self-hosted/observability/alerting#email) are configured in advanced configuration. 1. Click the _Code monitoring_ menu item at the top right of your page. 2. Click the _Create new code monitor_ button at the top right of the page. diff --git a/docs/code-navigation/auto-indexing.mdx b/docs/code-navigation/auto-indexing.mdx index 5bd9368cb..bf8a30eeb 100644 --- a/docs/code-navigation/auto-indexing.mdx +++ b/docs/code-navigation/auto-indexing.mdx @@ -25,7 +25,7 @@ First, [deploy the executor service](/self-hosted/executors) targeting your Sour ### Enable index job scheduling -Next, enable the following feature flag in your Sourcegraph instance's site configuration. +Next, enable the following feature flag in your Sourcegraph instance's advanced configuration. ```yaml {'codeIntelAutoIndexing.enabled': true} @@ -78,7 +78,7 @@ Precise code navigation indexing jobs are scheduled periodically in the backgrou ### Applying indexing policies globally -Site admins can create indexing policies that apply to **all repositories** on their Sourcegraph instance. In order to view and edit these policies, navigate to the code graph configuration in the site-admin dashboard. +Administrators can create indexing policies that apply to **all repositories** on their Sourcegraph instance. In order to view and edit these policies, navigate to the code graph configuration in the Administration dashboard. ![Global auto-indexing policy configuration list page](https://storage.googleapis.com/sourcegraph-assets/docs/images/code-intelligence/renamed/global-list-indexing.png) @@ -164,7 +164,7 @@ Users can see precise code navigation index jobs for a particular, repository by ![Repository index page](https://storage.googleapis.com/sourcegraph-assets/docs/images/code-intelligence/sg-3.33/repository-page.png) -Administrators of a Sourcegraph instance can see a global view of code graph index jobs across all repositories from the **Site Admin** page. +Administrators of a Sourcegraph instance can see a global view of code graph index jobs across all repositories from the **Administration** page. ![Global list of precise code navigation index jobs across all repositories](https://storage.googleapis.com/sourcegraph-assets/docs/images/code-intelligence/renamed/indexes-list.png) @@ -188,7 +188,7 @@ Once the index job completes, a code graph data file has been uploaded to the So When a commit of a repository is selected as a candidate for [auto-indexing](/code-navigation/auto-indexing) but does not have an explicitly supplied index job configuration, index jobs are inferred from the content of the repository at that commit. -The site-config setting `codeIntelAutoIndexing.indexerMap` can be used to update the indexer image that is (globally) used on inferred jobs. For example, `"codeIntelAutoIndexing.indexerMap": {"go": "lsif-go:alternative-tag"}` will cause inferred jobs indexing Go code to use the specified container (with an alternative tag). This can also be useful for specifying alternative Docker registries. +The advanced configuration setting `codeIntelAutoIndexing.indexerMap` can be used to update the indexer image that is (globally) used on inferred jobs. For example, `"codeIntelAutoIndexing.indexerMap": {"go": "lsif-go:alternative-tag"}` will cause inferred jobs indexing Go code to use the specified container (with an alternative tag). This can also be useful for specifying alternative Docker registries. This document describes the heuristics used to determine the set of index jobs to schedule. See [configuration reference](/code-navigation/auto-indexing-configuration) for additional documentation on how index jobs are configured. @@ -309,7 +309,7 @@ If the repository contains both a `lsif-java.json` file as well as `*.java`, `*. icon="theming" imgAlt="Code Navigation" title="Auto-indexing inference configuration reference" - description="Guide for site administrators on customizing code intelligence indexing jobs detection in Sourcegraph." + description="Guide for administrators on customizing code intelligence indexing jobs detection in Sourcegraph." /> -This document details how a site administrator can supply a Lua script to customize the way [Sourcegraph detects precise code intelligence indexing jobs from repository contents](/code-navigation/explanations/auto-indexing-inference). +This document details how an administrator can supply a Lua script to customize the way [Sourcegraph detects precise code intelligence indexing jobs from repository contents](/code-navigation/explanations/auto-indexing-inference). By default, Sourcegraph will attempt to infer index jobs for the following languages: @@ -15,7 +15,7 @@ By default, Sourcegraph will attempt to infer index jobs for the following langu - [`Rust`](/code-navigation/explanations/auto-indexing-inference#rust) - [`TypeScript`/`JavaScript`](/code-navigation/explanations/auto-indexing-inference#typescript) -Inference logic can be disabled or altered in the case when the target repositories do not conform to a pattern that the Sourcegraph default inference logic recognizes. Inference logic is controlled by a **Lua override script** that can be supplied in the UI under `Admin > Code graph > Inference`. +Inference logic can be disabled or altered in the case when the target repositories do not conform to a pattern that the Sourcegraph default inference logic recognizes. Inference logic is controlled by a **Lua override script** that can be supplied in the UI under `Administration > Code graph > Inference`. While the change is self-service, Sourcegraph support is more than happy to diff --git a/docs/code-navigation/private-maven-repository-configuration.mdx b/docs/code-navigation/private-maven-repository-configuration.mdx index 713ea992e..1795441dc 100644 --- a/docs/code-navigation/private-maven-repository-configuration.mdx +++ b/docs/code-navigation/private-maven-repository-configuration.mdx @@ -1,6 +1,6 @@ # Configuring Maven to Use a Private Repository for Auto-Indexing -Configuring Maven to use a private repository, such as Nexus or Artifactory, with Sourcegraph is essential when dependencies are retrieved from private repositories that require authentication (as opposed to public repositories such as Maven Central). This guide covers steps to set up Maven for [scip-java](https://sourcegraph.github.io/scip-java/) indexing with a private repository, ensuring secure and consistent dependency resolution. +Configuring Maven to use a private repository, such as Nexus or Artifactory, with Sourcegraph is essential when dependencies are retrieved from private repositories that require authentication (as opposed to public repositories such as Maven Central). This guide covers steps to set up Maven for [scip-java](https://scip-code.github.io/scip-java/) indexing with a private repository, ensuring secure and consistent dependency resolution. ## Testing the Configuration on a Single Repository @@ -40,7 +40,7 @@ After verifying the configuration on a single repository, you can automate the s ### Create or Update the Lua Script -Navigate to `site-admin -> Code Graph -> Inference`, and replace or add the following Lua script for [scip-java](https://sourcegraph.github.io/scip-java/) indexing with Maven’s `settings.xml` setup: +Navigate to `Administration -> Code Graph -> Inference`, and replace or add the following Lua script for [scip-java](https://scip-code.github.io/scip-java/) indexing with Maven’s `settings.xml` setup: ```lua local path = require("path") diff --git a/docs/code-navigation/syntactic-code-navigation.mdx b/docs/code-navigation/syntactic-code-navigation.mdx index d109d9bf4..3f7586b9c 100644 --- a/docs/code-navigation/syntactic-code-navigation.mdx +++ b/docs/code-navigation/syntactic-code-navigation.mdx @@ -21,7 +21,7 @@ but only if Precise data is not available. To summarize, the order of priorities ## Enabling Syntactic code navigation -First, enable the experimental feature flag in Site config: +First, enable the experimental feature flag in Advanced configuration: ```json "experimentalFeatures.codeintelSyntacticIndexing.enabled": true diff --git a/docs/code-navigation/troubleshooting.mdx b/docs/code-navigation/troubleshooting.mdx index 833d49be7..0413dd013 100644 --- a/docs/code-navigation/troubleshooting.mdx +++ b/docs/code-navigation/troubleshooting.mdx @@ -25,7 +25,7 @@ A customer issue should **not** be routed to code navigation if any of the follo ## Gathering evidence -Before bringing a code navigation issue to the engineering team, the site-admin or customer engineer should gather the following details. Not all of these details will be necessary for all classes of errors. +Before bringing a code navigation issue to the engineering team, the administrator or customer engineer should gather the following details. Not all of these details will be necessary for all classes of errors. ### Sourcegraph instance details @@ -68,7 +68,7 @@ The following user settings should be supplied if there is an issue with _displa - `basicCodeIntel.indexOnly` - `basicCodeIntel.unindexedSearchTimeout` -You can get your effective user settings (site-config + user settings override) with the following Sourcegraph CLI command. +You can get your effective user settings (advanced configuration + user settings override) with the following Sourcegraph CLI command. ```bash $ src api -query 'query ViewerSettings { viewerSettings { final } }' diff --git a/docs/code-search/faq.mdx b/docs/code-search/faq.mdx index 7e200055a..de435e9b3 100644 --- a/docs/code-search/faq.mdx +++ b/docs/code-search/faq.mdx @@ -14,7 +14,7 @@ Likewise, you can also [search through 1 million+ open source codebases](https:/ ### Do I need to enable Code Navigation? -No, the default search-based code navigation works out of the box without any configuration. However, for an advanced and customized navigation experience your site admin will set up precise code navigation. +No, the default search-based code navigation works out of the box without any configuration. However, for an advanced and customized navigation experience your administrator will set up precise code navigation. ### What is the max file size limit for Code Search? diff --git a/docs/code-search/features.mdx b/docs/code-search/features.mdx index cba9c882a..0b39d7cb6 100644 --- a/docs/code-search/features.mdx +++ b/docs/code-search/features.mdx @@ -63,7 +63,7 @@ See the [search contexts](/code-search/working/search-contexts) documentation to ## Multi-branch indexing -The most common branch to search is your default branch. To speed up this common operation, Sourcegraph maintains an index of the source code on your default branch. Some organizations have other branches that are regularly searched. To speed up search for those branches, Sourcegraph can be configured to index up to 64 branches per repository. Your site admin can configure multi-branch indexing through [site configuration](/admin/search#multi-branch-indexing). +The most common branch to search is your default branch. To speed up this common operation, Sourcegraph maintains an index of the source code on your default branch. Some organizations have other branches that are regularly searched. To speed up search for those branches, Sourcegraph can be configured to index up to 64 branches per repository. Your administrator can configure multi-branch indexing through [advanced configuration](/admin/search#multi-branch-indexing). ## Exclude files and directories diff --git a/docs/code-search/how-to/opengrok.mdx b/docs/code-search/how-to/opengrok.mdx index fa248db09..bce400cf3 100644 --- a/docs/code-search/how-to/opengrok.mdx +++ b/docs/code-search/how-to/opengrok.mdx @@ -29,7 +29,7 @@ Sourcegraph provides a search filter (`repo:`) that supports regexp and partial | - To search in a distinct list of repositories, you can use a ` |` character as a regexp OR operator: `pattern repo:github.com/org/repository1 | github.com/org/repository2`. | | - Note this query could be simplified further using more advanced regexp matching if the two repos share part of their names, such as: `pattern repo:github.com/org/repository(1 | 2)`. | | -Sourcegraph also allows users and site admins to create pre-defined repository groupings, using [search contexts](/code-search/working/search-contexts). +Sourcegraph also allows users and administrators to create pre-defined repository groupings, using [search contexts](/code-search/working/search-contexts). ### Searching in non-master (unindexed) branches, tags, and commits diff --git a/docs/code-search/queries/language.mdx b/docs/code-search/queries/language.mdx index 7ad10f6bb..88e4f1651 100644 --- a/docs/code-search/queries/language.mdx +++ b/docs/code-search/queries/language.mdx @@ -253,7 +253,7 @@ For example, - [`timeout:15s count:10000 func`](https://sourcegraph.com/search?q=repo:%5Egithub.com/sourcegraph/+timeout:15s+func+count:10000) sets a longer timeout for a search that contains a lot of results. -Sourcegraph admins can increase the maximum timeout of 1 minute through [site configuration](/admin/search#maximum-timeout). +Sourcegraph admins can increase the maximum timeout of 1 minute through [advanced configuration](/admin/search#maximum-timeout). The maximum timeout also depends on the HTTP load balancer or ingress diff --git a/docs/code-search/types/search-jobs.mdx b/docs/code-search/types/search-jobs.mdx index de9d22682..03bfa86c9 100644 --- a/docs/code-search/types/search-jobs.mdx +++ b/docs/code-search/types/search-jobs.mdx @@ -6,7 +6,7 @@ Search Jobs allow you to run search queries across your organization's codebase (all repositories, branches, and revisions) at scale. It enhances the existing Sourcegraph's search capabilities, enabling you to run searches without query timeouts or incomplete results. -With Search Jobs, you can start a search, let it run in the background, and then download the results from the Search Jobs UI when it's done. Site administrators can **enable** or **disable** the Search Jobs feature, making it accessible to all users on the Sourcegraph instance. +With Search Jobs, you can start a search, let it run in the background, and then download the results from the Search Jobs UI when it's done. Administrators can **enable** or **disable** the Search Jobs feature, making it accessible to all users on the Sourcegraph instance. ## Using Search Jobs @@ -18,7 +18,7 @@ To use Search Jobs: ![run-query-for-search-jobs](https://storage.googleapis.com/sourcegraph-assets/Docs/search-jobs/search-jobs-create.png) - If your query is valid, click **Create a search job** to initiate the search job -- You will be redirected to the "Search Jobs UI" page at `/search-jobs`, where you can view all your created search jobs. If you're a site admin, you can also view search jobs from other users on the instance +- You will be redirected to the "Search Jobs UI" page at `/search-jobs`, where you can view all your created search jobs. If you're an administrator, you can also view search jobs from other users on the instance - For each search job, you can download the results by clicking the **Download** button. The results are formatted as JSON lines, see [Search results format](#search-results-format) for more details. ![view-search-jobs](https://storage.googleapis.com/sourcegraph-assets/Docs/search-jobs/search-jobs-manage-with-frame.png) diff --git a/docs/code-search/types/structural.mdx b/docs/code-search/types/structural.mdx index 7726ca94b..28aaa78b8 100644 --- a/docs/code-search/types/structural.mdx +++ b/docs/code-search/types/structural.mdx @@ -8,8 +8,8 @@ {' '} Structural search is disabled by default. To enable it, - ask your site administrator to set experimentalFeatures.structuralSearch = - "enabled" in site configuration. Structural search has performance + ask your administrator to set experimentalFeatures.structuralSearch = + "enabled" in advanced configuration. Structural search has performance limitations and is not actively developed. We recommend using regex search or a combination of [Search Jobs](/code-search/types/search-jobs) and custom scripts instead. Please reach out to diff --git a/docs/code-search/working/saved-searches.mdx b/docs/code-search/working/saved-searches.mdx index ff5793f20..7a7e7d3a7 100644 --- a/docs/code-search/working/saved-searches.mdx +++ b/docs/code-search/working/saved-searches.mdx @@ -24,7 +24,7 @@ A `patternType:` filter is required in the query for all saved searches. `patter Enable the checkbox for **Draft** if you don't want other users to use your saved search. This is useful for testing the query before sharing it with others. Once done, click the **Create saved search** button to be redirected to the Saved Searches page. -Your saved search will appear with a `Secret` label, which means that only you can view and use it. To let others use your saved search, you need to transfer it to an organization and ask the site admin to make it public. +Your saved search will appear with a `Secret` label, which means that only you can view and use it. To let others use your saved search, you need to transfer it to an organization and ask the administrator to make it public. In addition, you can also search within your saved searches and sort your saved searches by name, recently updated, and description. diff --git a/docs/code-search/working/search-contexts.mdx b/docs/code-search/working/search-contexts.mdx index 6110103a1..6642ae003 100644 --- a/docs/code-search/working/search-contexts.mdx +++ b/docs/code-search/working/search-contexts.mdx @@ -11,7 +11,7 @@ Every search on Sourcegraph uses a search context. Search contexts can be define ## Available contexts - Contexts owned by a user, such as `context:@username/context-name`, which can be private to the user or public to all users on the Sourcegraph instance. -- Contexts at the global level, such as `context:example-context`, which can be private to site admins or public to all users on the Sourcegraph instance. +- Contexts at the global level, such as `context:example-context`, which can be private to administrators or public to all users on the Sourcegraph instance. - The global context, `context:global`, which includes all repositories on the Sourcegraph instance. ## Using search contexts @@ -38,15 +38,17 @@ If a user ever loses access to their default search context (eg. the search cont The default search context is always selected when loading the Sourcegraph webapp. The one exception is when opening a link to a search query that does not contain a `context:` filter, in which case the `global` context will be used. -#### For site admins + -Site admins can set a default search context for all users on the Sourcegraph instance. This helps teams improve onboarding and search quality by focusing searches on the most relevant parts of the codebase rather than the entire indexed set of repositories. +#### For administrators + +Administrators can set a default search context for all users on the Sourcegraph instance. This helps teams improve onboarding and search quality by focusing searches on the most relevant parts of the codebase rather than the entire indexed set of repositories. An admin can set a default search context via: - Click the **More** button from the menu of the Sourcegraph web app - Next, go to **Search Contexts** -- For the existing context list, click on the **...** menu and select **[Site admin only] Set as default for all users** +- For the existing context list, click on the **...** menu and select **[Administrator only] Set as default for all users** - Alternatively, you can create a new context and then set it for all users via the same option ![admin-level-default-context](https://storage.googleapis.com/sourcegraph-assets/Docs/admin-default-context.png) @@ -76,7 +78,7 @@ A search context consists of a name, description, and a set of repositories at o Contexts can be owned by a user, and can be private to the user or public to all users on the Sourcegraph instance. -Contexts can also be at the global instance level, and can be private to site admins or public to all users on the Sourcegraph instance. +Contexts can also be at the global instance level, and can be private to administrators or public to all users on the Sourcegraph instance. - Go to **More > Search contexts** in the navigation bar. - Press the **+ Create search context** button. @@ -85,7 +87,7 @@ Contexts can also be at the global instance level, and can be private to site ad - Optionally, enter a **Description** for the context. Markdown is supported. - Choose the **Visibility** of this context. - Public contexts are available to everyone on the Sourcegraph instance. Note that private repositories will only be visible to users that have permission to view the repository via the code host. - - Private contexts can only be viewed by their owner, or in the case being globally owned, by site admins. + - Private contexts can only be viewed by their owner, or in the case being globally owned, by administrators. - In the **Repositories and revisions** configuration, define which repositories and revisions should be included in the search context. Press **Add repository** to quickly add a template to the configuration. - Define repositories with valid URLs. - Define revisions as strings in an array. To specify a default branch, use `"HEAD"`. @@ -119,7 +121,7 @@ Search contexts can be defined with a restricted search query as an alternative `repo:has.content` etc, aren't currently supported in search contexts. -If you're an admin, to enable this feature for all users set `experimentalFeatures.searchContextsQuery` to `true` in your global settings (for regular users, just use the normal settings menu). You'll then see a "Create context" button from the search results page and a "Query" input field in the search contexts form. If you want revisions specified in these query based search contexts to be indexed, set `experimentalFeatures.search.index.query.contexts` to `true` in site configuration. +If you're an admin, to enable this feature for all users set `experimentalFeatures.searchContextsQuery` to `true` in your global settings (for regular users, just use the normal settings menu). You'll then see a "Create context" button from the search results page and a "Query" input field in the search contexts form. If you want revisions specified in these query based search contexts to be indexed, set `experimentalFeatures.search.index.query.contexts` to `true` in advanced configuration. ### Creating search contexts from search results diff --git a/docs/code-search/working/snippets.mdx b/docs/code-search/working/snippets.mdx index 8faef0b62..bde81ad4f 100644 --- a/docs/code-search/working/snippets.mdx +++ b/docs/code-search/working/snippets.mdx @@ -9,7 +9,7 @@ Every project and team has a different set of repositories they commonly work wi A search snippet is any valid query. For example, a search snippet that defines all repositories in the "example" organization would be `repo:^github\.com/example/`. After adding this snippet to your settings, it would appear in the search snippet panel in the search sidebar under a label of your choosing (as of v3.29). - Search snippets are temporarily named search.scopes in site configuration + Search snippets are temporarily named search.scopes in advanced configuration files. @@ -17,7 +17,7 @@ A search snippet is any valid query. For example, a search snippet that defines Custom search snippets can be specified at 3 different levels: -- By site admins for all users: in the **Global settings** in the site admin area. +- By administrators for all users: in the **Global settings** in the Administration area. - By organization admins for all organization members: in the organization profile **Settings** section - By users for themselves only: in the user profile **Settings** section diff --git a/docs/cody/capabilities/auto-edit.mdx b/docs/cody/capabilities/auto-edit.mdx index 7982dee00..fb2c6e54d 100644 --- a/docs/cody/capabilities/auto-edit.mdx +++ b/docs/cody/capabilities/auto-edit.mdx @@ -66,7 +66,7 @@ Auto-edit is supported by Cody VS Code, JetBrains, and Visual Studio plugins. Auto-edit is enabled by default for Cody Enterprise users. You can opt out and switch back to autocomplete by selecting it from the suggestion mode in the Cody VS Code extension settings. -Site admins can opt their organization out of the auto-edit feature by disabling it from their config settings. +Administrators can opt their organization out of the auto-edit feature by disabling it from their config settings. ### Configure auto-edit access @@ -113,7 +113,7 @@ The following example demonstrates how to add Fireworks as an allowed LLM provid Auto-edit is enabled by default for Cody Enterprise users. You can opt out and switch back to autocomplete by selecting it from the suggestion mode in the Cody JetBrains extension settings. -Site admins can opt their organization out of the auto-edit feature by disabling it from their config settings. +Administrators can opt their organization out of the auto-edit feature by disabling it from their config settings. - Click the three-dot menu on the top right of the Cody plugin window and select **Open Cody Settings Editor** - This will open the `cody_settings.json` file in your editor @@ -213,4 +213,4 @@ The following example demonstrates how to add Fireworks as an allowed LLM provid ## Disable auto-edit -To turn-off the auto-edit feature, set the feature flag `cody-autoedit-experiment-enabled-flag` as `disabled` in your site configuration. Doing so will switch back to autocomplete as your default suggestion mode. +To turn-off the auto-edit feature, set the feature flag `cody-autoedit-experiment-enabled-flag` as `disabled` in your advanced configuration. Doing so will switch back to autocomplete as your default suggestion mode. diff --git a/docs/cody/capabilities/autocomplete.mdx b/docs/cody/capabilities/autocomplete.mdx index ecf1b6ccb..07a76e93a 100644 --- a/docs/cody/capabilities/autocomplete.mdx +++ b/docs/cody/capabilities/autocomplete.mdx @@ -50,8 +50,8 @@ When you start typing, Cody will automatically provide suggestions and context-a By default, a fully configured Sourcegraph instance picks a default LLM to generate code autocomplete. Custom models can be used for Cody autocomplete based on your specific requirements. To do so: -- Go to the **Site admin** of your Sourcegraph instance -- Navigate to **Configuration > Site configuration** +- Go to **Administration** in your Sourcegraph instance +- Navigate to **Configuration > Advanced configuration** - Here, edit the `modelConfiguration` [section](/cody/enterprise/model-configuration) to include the autocomplete model you want to use - Click **Save** to save the changes diff --git a/docs/cody/capabilities/ignore-context.mdx b/docs/cody/capabilities/ignore-context.mdx index 8af5ff224..32db0bb83 100644 --- a/docs/cody/capabilities/ignore-context.mdx +++ b/docs/cody/capabilities/ignore-context.mdx @@ -14,7 +14,7 @@ Admins on the Sourcegraph Enterprise instance can use the Cody Context Filters t - Running the supported Cody client versions: VS Code `>=1.20.0` and JetBrains `>=6.0.0` - Setting the `cody-context-filters-enabled` feature flag to `true` -Site admins can customize the `cody.contextFilters` field in the site configuration to specify which repositories Cody should `include` or `exclude`, using the following structure: +Administrators can customize the `cody.contextFilters` field in the advanced configuration to specify which repositories Cody should `include` or `exclude`, using the following structure: ```json { diff --git a/docs/cody/capabilities/prompts.mdx b/docs/cody/capabilities/prompts.mdx index 1d6c516a2..a75801333 100644 --- a/docs/cody/capabilities/prompts.mdx +++ b/docs/cody/capabilities/prompts.mdx @@ -61,7 +61,7 @@ Once the prompt is visible, it's ready to be used by: - **The prompt's owner** if it is a user - **All members of the organization** if the prompt's owner is an organization -- **Everyone** if the prompt is marked **Public** (which only site admins can do) +- **Everyone** if the prompt is marked **Public** (which only administrators can do) ![prompts-in-vscode](https://storage.googleapis.com/sourcegraph-assets/Docs/prompt-in-vscode-2025.jpg) @@ -72,11 +72,11 @@ To edit a prompt, click the Edit button next to the prompt in the Prompt Library ## Prompt tags - Prompt tags are supported in Sourcegraph Enterprise, and only site admins + Prompt tags are supported in Sourcegraph Enterprise, and only administrators can create them. -Site admins can categorize prompts and create **tags**. This helps you keep your prompts organized, especially when there are many prompts to use and manage. +Administrators can categorize prompts and create **tags**. This helps you keep your prompts organized, especially when there are many prompts to use and manage. - Go to **Tools > Prompt Library** from your Enterprise Sourcegraph instance - From the left sidebar click **Manage** next to the **tags** list @@ -89,7 +89,7 @@ Once created, it will appear in the **Tags** list and in the sidebar of the Prom ### Assigning tags to prompts -Once site admins create tags, other users in your organization can assign tags to their prompts. While creating or editing a prompt, there is a drop-down selector **Add prompt to...** to assign tags to the prompt. +Once administrators create tags, other users in your organization can assign tags to their prompts. While creating or editing a prompt, there is a drop-down selector **Add prompt to...** to assign tags to the prompt. ![assign-prompt-tags](https://storage.googleapis.com/sourcegraph-assets/Docs/assign-prompt-tags-2025.png) @@ -133,7 +133,7 @@ However, prompts marked with the **Edit code** mode can only run from the IDE ed Promoted prompts are supported in VS Code and Cody Web. -**Site admins** can promote a prompt by enabling the **Promote prompt** checkbox. This setting allows admins to highlight prompts they want users to use. Promoted prompts are marked with an icon next to their name and appear at the top of the prompt list in the Cody chat. +**Administrators** can promote a prompt by enabling the **Promote prompt** checkbox. This setting allows admins to highlight prompts they want users to use. Promoted prompts are marked with an icon next to their name and appear at the top of the prompt list in the Cody chat. ![icon-recommended-prompts](https://storage.googleapis.com/sourcegraph-assets/Docs/recommended-prompts-icon-2025.png) diff --git a/docs/cody/clients/enable-cody-enterprise.mdx b/docs/cody/clients/enable-cody-enterprise.mdx index 922c19e53..d85b3c0b4 100644 --- a/docs/cody/clients/enable-cody-enterprise.mdx +++ b/docs/cody/clients/enable-cody-enterprise.mdx @@ -35,10 +35,10 @@ With [Sourcegraph Cloud](/cloud/), you get Cody as a managed service, and you ** ### Enable Cody on your Sourcegraph instance -Site admins can enable Cody on the Sourcegraph instance. To do so, +Administrators can enable Cody on the Sourcegraph instance. To do so, - First, configure your desired LLM provider either by [using Sourcegraph Model Provider (Cody Gateway)](/model-provider) or by directly using a third-party LLM provider -- Next, go to **Site admin > Site configuration** (`/site-admin/configuration`) on your instance and set: +- Next, go to **Administration > Advanced configuration** (`/site-admin/configuration`) on your instance and set: ```json { @@ -56,7 +56,7 @@ Site admins can enable Cody on the Sourcegraph instance. To do so, To turn Cody off: -- Go to **Site admin > Site configuration** (`/site-admin/configuration`) on your instance and set: +- Go to **Administration > Advanced configuration** (`/site-admin/configuration`) on your instance and set: ```json { @@ -69,7 +69,7 @@ To turn Cody off: Access to Cody is managed via user roles. By default, all users have access. -First, ensure Cody is enabled in your site configuration. Go to **Site admin > Site configuration** (`/site-admin/configuration`) on your instance and set: +First, ensure Cody is enabled in your advanced configuration. Go to **Administration > Advanced configuration** (`/site-admin/configuration`) on your instance and set: ```json { @@ -83,7 +83,7 @@ First, ensure Cody is enabled in your site configuration. Go to **Site admin > S configuration. If it is, remove it. -Next, go to **Site admin > Users & Auth > Roles** (`/site-admin/roles`) on your instance. On that page, you can: +Next, go to **Administration > Users & Auth > Roles** (`/site-admin/roles`) on your instance. On that page, you can: - Control whether users **by default** have access to Cody (expand `User [System]` and toggle **Cody** > **Access** as desired) - Control whether groups of users have access to Cody (`+Create role` and enable the **Cody** > **Access** toggle as desired) diff --git a/docs/cody/clients/install-jetbrains.mdx b/docs/cody/clients/install-jetbrains.mdx index 1d9d12b45..a287e4452 100644 --- a/docs/cody/clients/install-jetbrains.mdx +++ b/docs/cody/clients/install-jetbrains.mdx @@ -172,7 +172,7 @@ You can @-mention files and web pages in Cody. Cody Enterprise also supports @-m JetBrains plugin version `>=6.0.0`. -Admins on the Sourcegraph Enterprise instance can use Cody Context Filters to determine which repositories Cody can use as the context in its requests to third-party LLMs. Inside your site configuration, you can define a set of `include` and `exclude` rules that will be used to filter the list of repositories Cody can access. +Admins on the Sourcegraph Enterprise instance can use Cody Context Filters to determine which repositories Cody can use as the context in its requests to third-party LLMs. Inside your advanced configuration, you can define a set of `include` and `exclude` rules that will be used to filter the list of repositories Cody can access. For repos mentioned in the `exclude` field, Cody prompts are disabled, and you cannot use them for context fetching. If you try running any of these, you'll be prompted with an error message. However, Cody chat will still work, and you can use it to ask questions. @@ -221,7 +221,7 @@ All you need to do is select and highlight the code line with the error and clic ## Supported LLM models -Enterprise users who have [model configuration](/cody/enterprise/model-configuration#model-configuration) configured can also select from the available models for their instance. On instances with the ["completions" configuration](/cody/enterprise/model-configuration#completions-configuration), a site admin determines the LLM, which cannot be changed within the editor. +Enterprise users who have [model configuration](/cody/enterprise/model-configuration#model-configuration) configured can also select from the available models for their instance. On instances with the ["completions" configuration](/cody/enterprise/model-configuration#completions-configuration), an administrator determines the LLM, which cannot be changed within the editor. Read and learn more about the [supported diff --git a/docs/cody/clients/install-vscode.mdx b/docs/cody/clients/install-vscode.mdx index 09d99fab6..d4218c617 100644 --- a/docs/cody/clients/install-vscode.mdx +++ b/docs/cody/clients/install-vscode.mdx @@ -208,7 +208,7 @@ You can @-mention files, symbols, and web pages in Cody. It also supports @-ment Code extension version `>=1.20.0`. -Admins on the Sourcegraph Enterprise instance can use the Cody Context Filters to determine which repositories Cody can use as the context in its requests to third-party LLMs. Inside your site configuration, you can define a set of `include` and `exclude` rules that will be used to filter the list of repositories Cody can access. +Admins on the Sourcegraph Enterprise instance can use the Cody Context Filters to determine which repositories Cody can use as the context in its requests to third-party LLMs. Inside your advanced configuration, you can define a set of `include` and `exclude` rules that will be used to filter the list of repositories Cody can access. For repos mentioned in the `exclude` field, prompts are disabled, and you cannot use them for context fetching. If you try running any of these, you'll be prompted with an error message. However, Cody chat will still work, and you can use it to ask questions. @@ -268,7 +268,7 @@ Enterprise users get Claude 3.5 Sonnet as the default LLM models without extra c Provisioned throughput via AWS is not supported for 3.5 Sonnet. -You also get additional capabilities like BYOLLM (Bring Your Own LLM), supporting Single-Tenant and Self Hosted setups for flexible coding environments. Your site administrator determines the LLM, and cannot be changed within the editor. However, Cody Enterprise users when using Sourcegraph Model Provider (Cody Gateway) have the ability to [configure custom models](/model-provider#configuring-custom-models) from Anthropic, OpenAI, and Google Gemini. +You also get additional capabilities like BYOLLM (Bring Your Own LLM), supporting Single-Tenant and Self Hosted setups for flexible coding environments. Your administrator determines the LLM, and cannot be changed within the editor. However, Cody Enterprise users when using Sourcegraph Model Provider (Cody Gateway) have the ability to [configure custom models](/model-provider#configuring-custom-models) from Anthropic, OpenAI, and Google Gemini. Read more about all the supported LLM models diff --git a/docs/cody/core-concepts/context.mdx b/docs/cody/core-concepts/context.mdx index a8ba30633..f97783072 100644 --- a/docs/cody/core-concepts/context.mdx +++ b/docs/cody/core-concepts/context.mdx @@ -67,6 +67,6 @@ When the same prompt is sent to a standard LLM, the response may need more speci While Cody aims to provide maximum context for each prompt, there are limits to ensure efficiency. For more details, see our [docs on token limits](/cody/core-concepts/token-limits). -Site administrators can update the maximum context window size to meet their specific requirements. While using fewer tokens is a cost-saving solution, it can also cause errors. For example, using an `edit` or `describe` type prompts with a too small context window size might give you errors like `You've selected too much code`. +Administrators can update the maximum context window size to meet their specific requirements. While using fewer tokens is a cost-saving solution, it can also cause errors. For example, using an `edit` or `describe` type prompts with a too small context window size might give you errors like `You've selected too much code`. Using more tokens usually produces higher-quality responses but also increases response times. In general, it's recommended not to modify the token limit. However, if needed, you can set it to a value that should not compromise quality or generate errors. diff --git a/docs/cody/enterprise/completions-configuration.mdx b/docs/cody/enterprise/completions-configuration.mdx index 76f6c919e..97ebbc4cd 100644 --- a/docs/cody/enterprise/completions-configuration.mdx +++ b/docs/cody/enterprise/completions-configuration.mdx @@ -23,7 +23,7 @@ This is the recommended way to configure Cody Enterprise. It supports all the la ### Example: Your organization's Anthropic account -First, [create your own key with Anthropic](https://console.anthropic.com/account/keys). Once you have the key, go to **Site admin > Site configuration** (`/site-admin/configuration`) on your instance and set: +First, [create your own key with Anthropic](https://console.anthropic.com/account/keys). Once you have the key, go to **Administration > Advanced configuration** (`/site-admin/configuration`) on your instance and set: ```json { @@ -41,7 +41,7 @@ First, [create your own key with Anthropic](https://console.anthropic.com/accoun ### Example: Your organization's OpenAI account -First, [create your own key with OpenAI](https://beta.openai.com/account/api-keys). Once you have the key, go to **Site admin > Site configuration** (`/site-admin/configuration`) on your instance and set: +First, [create your own key with OpenAI](https://beta.openai.com/account/api-keys). Once you have the key, go to **Administration > Advanced configuration** (`/site-admin/configuration`) on your instance and set: ```json { @@ -71,7 +71,7 @@ Next, create an IAM user with programmatic access in your AWS account. Depending You can use instance role bindings or directly configure the IAM user credentials in the configuration. The `AWS_REGION` environment variable must also be set in the `frontend` container to scope the IAM credentials for the AWS region hosting the Bedrock endpoint. -Once ready, go to **Site admin > Site configuration** (`/site-admin/configuration`) on your instance and set: +Once ready, go to **Administration > Advanced configuration** (`/site-admin/configuration`) on your instance and set: ```json { @@ -123,7 +123,7 @@ On [GCP Vertex](https://cloud.google.com/vertex-ai/generative-ai/docs/partner-mo cat | base64 ``` -Once ready, go to **Site admin > Site configuration** (`/site-admin/configuration`) on your instance and set: +Once ready, go to **Administration > Advanced configuration** (`/site-admin/configuration`) on your instance and set: ```json { @@ -142,7 +142,7 @@ Once ready, go to **Site admin > Site configuration** (`/site-admin/configuratio For the `endpoint`, you can: - Go to the Claude 3 Haiku docs on the GCP Console Model garden -- Scroll through the page to find the example that shows how to use the `cURL` command with the Claude 3 Haiku model. The example will include a sample request JSON body and the necessary endpoint URL. Copy the URL in the site-admin config +- Scroll through the page to find the example that shows how to use the `cURL` command with the Claude 3 Haiku model. The example will include a sample request JSON body and the necessary endpoint URL. Copy the URL in the advanced configuration - The endpoint URL will look something like this: `https://LOCATION-aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/publishers/anthropic/models/` - Example URL: @@ -154,7 +154,7 @@ Create a project in the Azure OpenAI Service portal. From the project overview, Next, under **Model deployments**, click **manage deployments** and ensure you deploy the models you want, for example, `gpt-35-turbo`. Take note of the **deployment name**. -Once done, go to **Site admin > Site configuration** (`/site-admin/configuration`) on your instance and set: +Once done, go to **Administration > Advanced configuration** (`/site-admin/configuration`) on your instance and set: ```json { @@ -182,7 +182,7 @@ When tested with other coder models for the autocomplete use case, [StarCoder](h To ensure a fast and reliable experience, we are partnering with [Fireworks](https://fireworks.ai/) and have set up a dedicated hardware deployment for our Enterprise users. Sourcegraph supports StarCoder using the [Sourcegraph Model Provider (Cody Gateway)](/model-provider). -To enable StarCoder, go to **Site admin > Site configuration** (`/site-admin/configuration`) and change the `completionModel`: +To enable StarCoder, go to **Administration > Advanced configuration** (`/site-admin/configuration`) and change the `completionModel`: ```json { diff --git a/docs/cody/enterprise/features.mdx b/docs/cody/enterprise/features.mdx index 4fc93dd77..5d6497b1c 100644 --- a/docs/cody/enterprise/features.mdx +++ b/docs/cody/enterprise/features.mdx @@ -7,7 +7,7 @@ ## IDE token expiry -Site administrators can set the duration of access tokens for users connecting Cody from their IDEs (VS Code, JetBrains, etc.). This can be configured from the **Site admin** page of the Sourcegraph Enterprise instance. Available options include **7, 14, 30, 60, and 90 days**. +Administrators can set the duration of access tokens for users connecting Cody from their IDEs (VS Code, JetBrains, etc.). This can be configured from the **Administration** page of the Sourcegraph Enterprise instance. Available options include **7, 14, 30, 60, and 90 days**. ![ide-token-expiry](https://storage.googleapis.com/sourcegraph-assets/Docs/token-expiry.png) @@ -26,13 +26,13 @@ Site administrators can set the duration of access tokens for users connecting C Open source attribution guardrails for public code, commonly called copyright guardrails, reduce the exposure to copyrighted code. This involves implementing a verification mechanism within Cody to ensure that any code generated by the platform does not replicate open source code. -Guardrails for public code are available to all Sourcegraph Enterprise instances and are **disabled** by default. You can enable them from the Site configuration section by setting `attribution.enabled` to `true`. +Guardrails for public code are available to all Sourcegraph Enterprise instances and are **disabled** by default. You can enable them from the Advanced configuration section by setting `attribution.enabled` to `true`. Guardrails don't differentiate between license types. It matches any code snippet that is at least **ten lines** long from the **290,000** indexed open source repositories. ### Guardrails `enforced` check -You can `enforce` a Guardrails check to prevent any matching code from being shown to the user. To do so, site admins need to add `"attribution.mode": "enforced"` in the **Site configuration** setting. This will configure the settings for Cody IDE extensions VS Code (v1.82+) or JetBrains (v7.82+) accordingly and will enforce not to display code until attribution checks have finished. +You can `enforce` a Guardrails check to prevent any matching code from being shown to the user. To do so, administrators need to add `"attribution.mode": "enforced"` in the **Advanced configuration** setting. This will configure the settings for Cody IDE extensions VS Code (v1.82+) or JetBrains (v7.82+) accordingly and will enforce not to display code until attribution checks have finished. ### Known Limitations @@ -47,7 +47,7 @@ You can `enforce` a Guardrails check to prevent any matching code from being sho Admin controls are supported with VS Code and JetBrains IDE extension. -Site administrators have selective control over users' access to Cody Enterprise, which is managed via the Sourcegraph role-based access control system. This provides a more intuitive user interface for assigning permission to use Cody. +Administrators have selective control over users' access to Cody Enterprise, which is managed via the Sourcegraph role-based access control system. This provides a more intuitive user interface for assigning permission to use Cody. ## Analytics @@ -92,11 +92,11 @@ If you want to include recent changes that haven't been indexed in your Sourcegr ## Prompt pre-instructions -**Site admins** can add and configure prompt pre-instructions for Cody. These are text instructions that Cody uses with every chat query, allowing organizations to configure how Cody responds to their users. +**Administrators** can add and configure prompt pre-instructions for Cody. These are text instructions that Cody uses with every chat query, allowing organizations to configure how Cody responds to their users. For example, if you don’t want Cody to answer questions relating to sensitive non-code matters, you can pre-instruct Cody about it. In this case, if a user asks an unrelated question, Cody responds with a pre-instructed context. -To configure pre-instructions, add the following to your site admin configuration file: +To configure pre-instructions, add the following to your advanced configuration file: ```json { ... "modelConfiguration": { "systemPreInstruction": "If the question is not directly related to software development, respond with \"I can only answer programming-related questions\"" } } diff --git a/docs/cody/enterprise/model-config-examples.mdx b/docs/cody/enterprise/model-config-examples.mdx index c183ea594..400de144b 100644 --- a/docs/cody/enterprise/model-config-examples.mdx +++ b/docs/cody/enterprise/model-config-examples.mdx @@ -807,7 +807,7 @@ See also [Debugging: running a latency test](#debugging-running-a-latency-test). more. -Site administrators can test completions latency by sending a special debug command in any Cody chat window (in the web, in the editor, etc.): +Administrators can test completions latency by sending a special debug command in any Cody chat window (in the web, in the editor, etc.): ```shell cody_debug:::{"latencytest": 100} @@ -834,7 +834,7 @@ This can be helpful to get a feel for the latency of particular models, or model Few important considerations: -- Debug commands are only available to site administrators and have no effect when used by regular users. +- Debug commands are only available to administrators and have no effect when used by regular users. - Sourcegraph's built-in Grafana monitoring also has a full `Completions` dashboard for monitoring LLM requests, performance, etc. diff --git a/docs/cody/enterprise/model-configuration.mdx b/docs/cody/enterprise/model-configuration.mdx index 17d47d9bf..ab0965622 100644 --- a/docs/cody/enterprise/model-configuration.mdx +++ b/docs/cody/enterprise/model-configuration.mdx @@ -10,15 +10,15 @@ autocomplete models. -The `modelConfiguration` field in the **Site config** section allows you to configure Cody to use different LLM models for chat and autocomplete, enabling greater flexibility in selecting the best model for your needs. +The `modelConfiguration` field in the **Advanced configuration** section allows you to configure Cody to use different LLM models for chat and autocomplete, enabling greater flexibility in selecting the best model for your needs. Using this configuration, you get an LLM selector in the Cody chat with an Enterprise instance that allows you to select the model you want to use. -The LLM models available for a Sourcegraph Enterprise instance offer a combination of Sourcegraph-provided models and any custom models providers that you explicitly add to your Sourcegraph instance site configuration. +The LLM models available for a Sourcegraph Enterprise instance offer a combination of Sourcegraph-provided models and any custom models providers that you explicitly add to your Sourcegraph instance advanced configuration. ## `modelConfiguration` -The model configuration for Cody is managed through the `"modelConfiguration"` field in the **Site config** section. It includes the following fields: +The model configuration for Cody is managed through the `"modelConfiguration"` field in the **Advanced configuration** section. It includes the following fields: | **Field** | **Description** | | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | @@ -36,11 +36,11 @@ For a minimal configuration example, see [Configure Sourcegraph-supplied models] ## Sourcegraph-provided models -Sourcegraph-provided models, accessible through the [Sourcegraph Model Provider (Cody Gateway)](/model-provider), are managed via your site configuration. +Sourcegraph-provided models, accessible through the [Sourcegraph Model Provider (Cody Gateway)](/model-provider), are managed via your advanced configuration. For most administrators, relying on these models alone ensures access to high-quality models without needing to manage specific configurations. See [Supported LLMs](/cody/capabilities/supported-models) for the full list of available models. -The use of these models is controlled through the `"modelConfiguration.sourcegraph"` field in the site config. +The use of these models is controlled through the `"modelConfiguration.sourcegraph"` field in the advanced configuration. Sourcegraph-provided models through Cody Gateway have context window @@ -79,7 +79,7 @@ There are three main settings for configuring Sourcegraph-provided LLM models: ### Disable Sourcegraph-provided models -To disable all Sourcegraph-provided models and use only the models explicitly defined in your site configuration, set the `"sourcegraph"` field to `null` as shown in the example below. +To disable all Sourcegraph-provided models and use only the models explicitly defined in your advanced configuration, set the `"sourcegraph"` field to `null` as shown in the example below. ```json "cody.enabled": true, @@ -147,9 +147,9 @@ The following examples demonstrate how to use each of these settings together: A `provider` is an organizational concept for grouping LLM models. Typically, a provider refers to the company that produced the model or the specific API/service used to access it, serving as a namespace. -By defining a provider override in your Sourcegraph site configuration, you can introduce a new namespace to organize models or customize the existing provider namespace supplied by Sourcegraph (e.g., for all `"anthropic"` models). +By defining a provider override in your Sourcegraph advanced configuration, you can introduce a new namespace to organize models or customize the existing provider namespace supplied by Sourcegraph (e.g., for all `"anthropic"` models). -Provider overrides are configured via the `"modelConfiguration.providerOverrides"` field in the site configuration. +Provider overrides are configured via the `"modelConfiguration.providerOverrides"` field in the advanced configuration. This field is an array of items, each containing the following fields: | **Field** | **Description** | @@ -497,7 +497,7 @@ The response includes: Sourcegraph Enterprise customers using AWS Bedrock or Google Vertex. -Reasoning models can be added via `modelOverrides` in the site configuration by adding the `reasoning` capability to the `capabilities` list, and setting the `reasoningEffort` field on the model. Both must be set for the models' reasoning functionality to be used (otherwise the base model without reasoning / extended thinking will be used.) +Reasoning models can be added via `modelOverrides` in the advanced configuration by adding the `reasoning` capability to the `capabilities` list, and setting the `reasoningEffort` field on the model. Both must be set for the models' reasoning functionality to be used (otherwise the base model without reasoning / extended thinking will be used.) For example, this `modelOverride` would create a `Claude Sonnet 4 with Thinking` option in the Cody model selector menu, and when the user chats with Cody with that model selected, it would use Claude Sonnet 4's Extended Thinking support with a `low` reasoning effort for the users' chat: diff --git a/docs/cody/prompts-guide.mdx b/docs/cody/prompts-guide.mdx index df3e993a9..1e612078e 100644 --- a/docs/cody/prompts-guide.mdx +++ b/docs/cody/prompts-guide.mdx @@ -222,7 +222,7 @@ Try adding any supplementary details regarding comments, debugging guidelines, e ## Prompts Library -To accelerate and automate your work, you can leverage Cody's Prompt Library, which helps you build customizable building blocks (prompts), share your best prompts with your teammates, and enable site administrators to promote the best prompts to the rest of the organization. +To accelerate and automate your work, you can leverage Cody's Prompt Library, which helps you build customizable building blocks (prompts), share your best prompts with your teammates, and enable administrators to promote the best prompts to the rest of the organization. The Prompt Library is a system for creating and sharing customizable prompts. It is explicitly designed for scalability, repeatability, and flexibility. diff --git a/docs/context-filters.mdx b/docs/context-filters.mdx index 19935d541..5fa92903e 100644 --- a/docs/context-filters.mdx +++ b/docs/context-filters.mdx @@ -2,7 +2,7 @@ Supported on [Enterprise](/pricing/plans/enterprise) plans. Configuring - context filters requires site-admin access. + context filters requires administrator access. Context filters are an admin-defined exclusion list for [Deep Search](/deep-search). Anything matched by a filter is invisible to the agent: it never appears in an answer, and it cannot be read, searched, diffed, or resolved by any Deep Search tool. @@ -20,7 +20,7 @@ To Deep Search, excluded content is indistinguishable from content that does not ## Configuring context filters -A site admin configures filters under **Admin → Configuration → Advanced configuration**, inside the `experimentalFeatures` block of the site configuration. Each entry in `exclude` is an independent rule, and content is hidden if it matches any rule. +An administrator configures filters under **Administration → Configuration → Advanced configuration**, inside the `experimentalFeatures` block of the advanced configuration. Each entry in `exclude` is an independent rule, and content is hidden if it matches any rule. ```jsonc "experimentalFeatures": { diff --git a/docs/deep-search/index.mdx b/docs/deep-search/index.mdx index 950713035..fa6fdbb92 100644 --- a/docs/deep-search/index.mdx +++ b/docs/deep-search/index.mdx @@ -107,7 +107,7 @@ We do not enforce [repository permissions](/admin/permissions) for viewing share ## Enabling Deep Search -If Deep Search is disabled, ask your site administrator to enable the following setting in your site configuration: +If Deep Search is disabled, ask your administrator to enable the following setting in your advanced configuration: ```json "deepSearch.enabled": true, @@ -117,7 +117,7 @@ Deep Search uses a combination of frontier and specialized models selected by So ### Enabling conversation sharing -To enable conversation sharing, ask your site administrator to enable the following setting in your site configuration: +To enable conversation sharing, ask your administrator to enable the following setting in your advanced configuration: ```json "deepSearch.enabled": true, diff --git a/docs/getting-started/cloud-instance.mdx b/docs/getting-started/cloud-instance.mdx index 53ee69666..7d55fd2e3 100644 --- a/docs/getting-started/cloud-instance.mdx +++ b/docs/getting-started/cloud-instance.mdx @@ -25,13 +25,13 @@ Sourcegraph supports out-of-the-box support for different auth providers. Our do - [User authentication (SSO) - Sourcegraph docs](/admin/auth) -You may not have the right privileges or role in your team to set this up. In that case, you could invite someone with the right privileges and make them a site-admin. +You may not have the right privileges or role in your team to set this up. In that case, you could invite someone with the right privileges and make them an administrator. ### Inviting Single Users Getting users into Sourcegraph is easy, you just need to navigate to: -**Site Admin** → **Users and auth** → **Users** → **+ Create user** +**Administration** → **Users and auth** → **Users** → **+ Create user** ## Setup Email Server diff --git a/docs/integration/aws-codecommit.mdx b/docs/integration/aws-codecommit.mdx index 46eb9ef9b..b6f5c67de 100644 --- a/docs/integration/aws-codecommit.mdx +++ b/docs/integration/aws-codecommit.mdx @@ -9,7 +9,7 @@ You can use Sourcegraph with Git repositories hosted on [AWS CodeCommit](https:/ ## Repository syncing -Site admins can [add AWS CodeCommit repositories to Sourcegraph](/admin/code-hosts/aws-codecommit). +Administrators can [add AWS CodeCommit repositories to Sourcegraph](/admin/code-hosts/aws-codecommit). ## Browser extension diff --git a/docs/integration/bitbucket-cloud.mdx b/docs/integration/bitbucket-cloud.mdx index 4a6dfce1d..81107c30a 100644 --- a/docs/integration/bitbucket-cloud.mdx +++ b/docs/integration/bitbucket-cloud.mdx @@ -11,9 +11,9 @@ You can use Sourcegraph with Git repositories hosted on [Bitbucket Cloud](https: ## Repository syncing -Site admins can [add Bitbucket Cloud repositories to Sourcegraph](/admin/code-hosts/bitbucket-cloud). +Administrators can [add Bitbucket Cloud repositories to Sourcegraph](/admin/code-hosts/bitbucket-cloud). ## User authorization -Site admins can [add Bitbucket Cloud as an authentication provider to Sourcegraph](/admin/auth#bitbucket-cloud). -This will allow users to sign into Sourcegraph using their Bitbucket Cloud accounts. Site admins can then also [enable repository permissions](/admin/code-hosts/bitbucket-cloud#repository-permissions) on their Bitbucket Cloud code host connections. +Administrators can [add Bitbucket Cloud as an authentication provider to Sourcegraph](/admin/auth#bitbucket-cloud). +This will allow users to sign into Sourcegraph using their Bitbucket Cloud accounts. Administrators can then also [enable repository permissions](/admin/code-hosts/bitbucket-cloud#repository-permissions) on their Bitbucket Cloud code host connections. diff --git a/docs/integration/bitbucket-server.mdx b/docs/integration/bitbucket-server.mdx index 966a5ea9a..a092b7f35 100644 --- a/docs/integration/bitbucket-server.mdx +++ b/docs/integration/bitbucket-server.mdx @@ -12,11 +12,11 @@ You can use Sourcegraph with Git repositories hosted on [Bitbucket Server](https ## Repository syncing -Site admins can [add Bitbucket Server / Bitbucket Data Center repositories to Sourcegraph](/admin/code-hosts/bitbucket-server). +Administrators can [add Bitbucket Server / Bitbucket Data Center repositories to Sourcegraph](/admin/code-hosts/bitbucket-server). ## Repository permissions -Site admins can [configure Sourcegraph to respect Bitbucket Server / Bitbucket Data Center's repository access permissions](/admin/code-hosts/bitbucket-server#repository-permissions). +Administrators can [configure Sourcegraph to respect Bitbucket Server / Bitbucket Data Center's repository access permissions](/admin/code-hosts/bitbucket-server#repository-permissions). ## Sourcegraph Bitbucket Plugin @@ -29,7 +29,7 @@ We recommend installing the Sourcegraph Bitbucket plugin which adds the followin Install the Sourcegraph plugin for Bitbucket from the [Atlassian Marketplace](https://marketplace.atlassian.com/apps/1231975/sourcegraph-for-bitbucket?tab=overview&hosting=datacenter) or see the [bitbucket-server-plugin](https://github.com/sourcegraph/bitbucket-server-plugin) repository for instructions on how to manually install the plugin on your Bitbucket Server / Bitbucket Data Center instance. -For the Bitbucket Server plugin to then communicate with the Sourcegraph instance, the Sourcegraph site configuration must be updated to include the [`corsOrigin` property](/admin/config/site-config) with the Bitbucket Server / Bitbucket Data Center URL +For the Bitbucket Server plugin to then communicate with the Sourcegraph instance, the Sourcegraph advanced configuration must be updated to include the [`corsOrigin` property](/admin/config/site-config) with the Bitbucket Server / Bitbucket Data Center URL ```json { diff --git a/docs/integration/browser-extension/references/privacy.mdx b/docs/integration/browser-extension/references/privacy.mdx index 14feb355a..241e6b5cd 100644 --- a/docs/integration/browser-extension/references/privacy.mdx +++ b/docs/integration/browser-extension/references/privacy.mdx @@ -2,7 +2,7 @@ Sourcegraph integrations will only connect to Sourcegraph.com as required to provide code navigation or other functionality on public code. As a result, no private code, private repository names, usernames, or any other specific data is sent to Sourcegraph.com. -If connected to a **private, self-hosted Sourcegraph instance**, Sourcegraph integrations never send any logs, pings, usage statistics, or telemetry to Sourcegraph.com. They will send notifications of usage to that private Sourcegraph instance only. This allows the site admins to see usage statistics. +If connected to a **private, self-hosted Sourcegraph instance**, Sourcegraph integrations never send any logs, pings, usage statistics, or telemetry to Sourcegraph.com. They will send notifications of usage to that private Sourcegraph instance only. This allows the administrators to see usage statistics. If connected to the **public Sourcegraph.com instance**, Sourcegraph integrations will send notifications of usage on public repositories to Sourcegraph.com. diff --git a/docs/integration/github.mdx b/docs/integration/github.mdx index ba4fc0476..6259d6593 100644 --- a/docs/integration/github.mdx +++ b/docs/integration/github.mdx @@ -11,15 +11,15 @@ You can use Sourcegraph with [GitHub.com](https://github.com) and [GitHub Enterp ## Repository syncing -Site admins can [add GitHub repositories to Sourcegraph](/admin/code-hosts/github#selecting-repositories-to-sync). +Administrators can [add GitHub repositories to Sourcegraph](/admin/code-hosts/github#selecting-repositories-to-sync). ## Repository permissions -Site admins can [configure Sourcegraph to respect GitHub repository access permissions](/admin/code-hosts/github#repository-permissions). +Administrators can [configure Sourcegraph to respect GitHub repository access permissions](/admin/code-hosts/github#repository-permissions). ## User authentication -Site admins can [configure Sourcegraph to allow users to sign in via GitHub](/admin/code-hosts/github#user-authentication). +Administrators can [configure Sourcegraph to allow users to sign in via GitHub](/admin/code-hosts/github#user-authentication). ## Browser extension diff --git a/docs/integration/gitlab.mdx b/docs/integration/gitlab.mdx index f2e746ba2..b60b96736 100644 --- a/docs/integration/gitlab.mdx +++ b/docs/integration/gitlab.mdx @@ -12,15 +12,15 @@ You can use Sourcegraph with [GitLab.com](https://gitlab.com) and GitLab CE/EE. ## Repository syncing -Site admins can [add GitLab repositories to Sourcegraph](/admin/code-hosts/gitlab#repository-syncing). +Administrators can [add GitLab repositories to Sourcegraph](/admin/code-hosts/gitlab#repository-syncing). ## Repository permissions -Site admins can [configure Sourcegraph to respect GitLab repository access permissions](/admin/code-hosts/gitlab#repository-permissions). +Administrators can [configure Sourcegraph to respect GitLab repository access permissions](/admin/code-hosts/gitlab#repository-permissions). ## User authentication -Site admins can [configure Sourcegraph to allow users to sign in via GitLab](/admin/code-hosts/gitlab#user-authentication). +Administrators can [configure Sourcegraph to allow users to sign in via GitLab](/admin/code-hosts/gitlab#user-authentication). ## GitLab UI native integration diff --git a/docs/integration/gitolite.mdx b/docs/integration/gitolite.mdx index a5a2fc986..4342fbce8 100644 --- a/docs/integration/gitolite.mdx +++ b/docs/integration/gitolite.mdx @@ -9,7 +9,7 @@ You can use Sourcegraph with [Gitolite](https://gitolite.com/). ## Repository syncing -Site admins can [sync Gitolite repositories to Sourcegraph](/admin/code-hosts/gitolite#repository-syncing). +Administrators can [sync Gitolite repositories to Sourcegraph](/admin/code-hosts/gitolite#repository-syncing). ## Browser extension diff --git a/docs/integration/phabricator.mdx b/docs/integration/phabricator.mdx index 64331e99e..240d6384b 100644 --- a/docs/integration/phabricator.mdx +++ b/docs/integration/phabricator.mdx @@ -15,7 +15,7 @@ This Phabricator integration does not support listing and mirroring Phabricator ## Repository association -Site admins can [associate Phabricator repositories with Sourcegraph](/admin/code-hosts/phabricator#repository-syncing-and-linking). +Administrators can [associate Phabricator repositories with Sourcegraph](/admin/code-hosts/phabricator#repository-syncing-and-linking). ## Browser extension @@ -30,4 +30,4 @@ The [Sourcegraph browser extension](/integration/browser-extension) supports Pha - Click "Allow" in the permissions request popup. 1. Visit any file or diff on Phabricator. Hover over code or click the "View file" and "View repository" buttons. -> NOTE: Site admins can also install the [native Phabricator extension](/admin/code-hosts/phabricator#native-extension) to avoid needing each user to install the browser extension. +> NOTE: Administrators can also install the [native Phabricator extension](/admin/code-hosts/phabricator#native-extension) to avoid needing each user to install the browser extension. diff --git a/docs/model-provider/index.mdx b/docs/model-provider/index.mdx index 76924691c..6eb5e823e 100644 --- a/docs/model-provider/index.mdx +++ b/docs/model-provider/index.mdx @@ -24,7 +24,7 @@ The Sourcegraph Model Provider is the default and recommended way to configure A manager. -To enable inference provided by the Sourcegraph Model Provider on your Sourcegraph Enterprise instance, all you need to do is ensure your license key and your model provider is set to `"sourcegraph"` in your [site configuration](/admin/config/site-config): +To enable inference provided by the Sourcegraph Model Provider on your Sourcegraph Enterprise instance, all you need to do is ensure your license key and your model provider is set to `"sourcegraph"` in your [advanced configuration](/admin/config/site-config): ```jsonc { diff --git a/docs/self-hosted/advanced-config-file.mdx b/docs/self-hosted/advanced-config-file.mdx index 6a88d343b..0359f3cae 100644 --- a/docs/self-hosted/advanced-config-file.mdx +++ b/docs/self-hosted/advanced-config-file.mdx @@ -1,13 +1,13 @@ # Loading configuration via the file system (declarative config) -Some teams require Sourcegraph configuration to be stored in version control as opposed to editing via the Site admin +Some teams require Sourcegraph configuration to be stored in version control as opposed to editing via the Administration UI. ## Benefits 1. Configuration can be checked into version control (e.g., Git). 2. Configuration is enforced across the entire instance, and edits cannot be made via the web UI (by default). -3. Declarative site-config +3. Declarative advanced configuration 4. Sourcegraph watches the config file for changes and applies any new updates to the corresponding external services. ## Drawbacks @@ -18,27 +18,31 @@ Loading configuration in this manner has two significant drawbacks: scratch space, though). 2. Sourcegraph sometimes performs automatic migrations of configuration when upgrading versions. This process will now be more manual for you (see below). -3. Site-config contains **sensitive information** (see [Merging site config](#merging-site-configuration) for +3. Advanced configuration contains **sensitive information** (see [Merging advanced configuration](#merging-site-configuration) for mitigations) -## Site configuration + + +## Advanced configuration Set `SITE_CONFIG_FILE=site.json` and mount the config on: - [Docker Compose](/self-hosted/deploy/docker-compose/) and [Kubernetes](/self-hosted/deploy/kubernetes/): all `frontend` containers -Where `site.json` is a file that contains the [site configuration](/admin/config/site-config), which you would otherwise edit -through the in-app site configuration editor. +Where `site.json` is a file that contains the [advanced configuration](/admin/config/site-config), which you would otherwise edit +through the in-app advanced configuration editor. If you want to _allow_ edits to be made through the web UI (which will be overwritten with what is in the file on a subsequent restart), you may additionally set `SITE_CONFIG_ALLOW_EDITS=true`. > NOTE: If you do enable this, it is your responsibility to ensure the configuration on your instance and in the file remain in sync. -### Merging site-configuration + + +### Merging advanced configuration -You may separate your site-config into a sensitive and non-sensitive `jsonc` / `json`. Set the env +You may separate your advanced configuration into a sensitive and non-sensitive `jsonc` / `json`. Set the env var `SITE_CONFIG_FILE=/etc/site.json:/other/sensitive-site-config.json`. Note the path separator of `:` This will merge both files. Sourcegraph will need access both files. @@ -129,12 +133,12 @@ It will still perform such migrations on the configuration loaded from file, it When you upgrade Sourcegraph, you should do the following to ensure your configurations do not become invalid: 1. Upgrade Sourcegraph to the new version -1. Visit each configuration page in the web UI (management console, site configuration, each code host) +1. Visit each configuration page in the web UI (management console, advanced configuration, each code host) 1. Copy the (now migrated) configuration from those pages into your JSON files. It is essential to follow the above steps after **every** Sourcegraph version update, because we only guarantee migrations remain valid across two minor versions. If you fail to apply a migration and later upgrade Sourcegraph twice more, you may effectively "skip" an important migration. -We're planning to improve this by having Sourcegraph notify you as a site admin when you should do the above, since today it is not actually required in most upgrades. In the meantime, we will do our best to communicate when this is needed to you through the changelog. +We're planning to improve this by having Sourcegraph notify you as an administrator when you should do the above, since today it is not actually required in most upgrades. In the meantime, we will do our best to communicate when this is needed to you through the changelog. ## Kubernetes ConfigMap diff --git a/docs/self-hosted/deploy/docker-compose/azure.mdx b/docs/self-hosted/deploy/docker-compose/azure.mdx index c3da09d1b..874ff7d5e 100644 --- a/docs/self-hosted/deploy/docker-compose/azure.mdx +++ b/docs/self-hosted/deploy/docker-compose/azure.mdx @@ -164,7 +164,7 @@ tail -c +0 -f /var/log/syslog | grep cloud-init docker ps --filter="name=sourcegraph-frontend-0" ``` -> NOTE: If you have configured a DNS entry for the IP, please ensure to update `externalURL` in your Sourcegraph instance's Site Configuration to reflect that +> NOTE: If you have configured a DNS entry for the IP, please ensure to update `externalURL` in your Sourcegraph instance's Advanced Configuration to reflect that --- @@ -191,4 +191,4 @@ Postgres service will get Sourcegraph back to its previous state. ## Other resources [HTTP and HTTPS/SSL configuration](/self-hosted/http-https-configuration#sourcegraph-via-docker-compose-caddy-2) -[Site Administration Quickstart](/admin/how-to/site-admin-quickstart) +[Administration Quickstart](/admin/how-to/site-admin-quickstart) diff --git a/docs/self-hosted/deploy/docker-compose/configuration.mdx b/docs/self-hosted/deploy/docker-compose/configuration.mdx index 6e533ca91..0ebdc5985 100644 --- a/docs/self-hosted/deploy/docker-compose/configuration.mdx +++ b/docs/self-hosted/deploy/docker-compose/configuration.mdx @@ -61,7 +61,7 @@ To enable tracing on your instance, you'll need to either: 1. Deploy our bundled Jaeger backend, or 2. Configure an external tracing backend -Once a tracing backend has been deployed, see our [Tracing](/self-hosted/observability/tracing) page for next steps, including required changes to your Site Configuration to enable traces. +Once a tracing backend has been deployed, see our [Tracing](/self-hosted/observability/tracing) page for next steps, including required changes to your Advanced Configuration to enable traces. ### Deploy the bundled Jaeger diff --git a/docs/self-hosted/deploy/docker-compose/digitalocean.mdx b/docs/self-hosted/deploy/docker-compose/digitalocean.mdx index 3a20173b1..4246d149c 100644 --- a/docs/self-hosted/deploy/docker-compose/digitalocean.mdx +++ b/docs/self-hosted/deploy/docker-compose/digitalocean.mdx @@ -153,7 +153,7 @@ After the initial deployment has been completed, it is strongly recommended to s Firewalls](https://www.digitalocean.com/docs/networking/firewalls/quickstart/). - Set up [TLS/SSL](/self-hosted/http-https-configuration#sourcegraph-via-docker-compose-caddy-2) in the Docker Compose deployment -> NOTE: If you have configured a DNS entry for the IP, please ensure to update `externalURL` in your Sourcegraph instance's Site Configuration to reflect that +> NOTE: If you have configured a DNS entry for the IP, please ensure to update `externalURL` in your Sourcegraph instance's Advanced Configuration to reflect that --- @@ -180,4 +180,4 @@ get Sourcegraph back to its previous state. ## Other resources [HTTP and HTTPS/SSL configuration](/self-hosted/http-https-configuration#sourcegraph-via-docker-compose-caddy-2) -[Site Administration Quickstart](/admin/how-to/site-admin-quickstart) +[Administration Quickstart](/admin/how-to/site-admin-quickstart) diff --git a/docs/self-hosted/deploy/docker-compose/google-cloud.mdx b/docs/self-hosted/deploy/docker-compose/google-cloud.mdx index d6579be0b..5f6808354 100644 --- a/docs/self-hosted/deploy/docker-compose/google-cloud.mdx +++ b/docs/self-hosted/deploy/docker-compose/google-cloud.mdx @@ -143,7 +143,7 @@ tail -c +0 -f /var/log/syslog | grep startup-script docker ps --filter="name=sourcegraph-frontend-0" ``` -> NOTE: If you have configured a DNS entry for the IP, please ensure to update `externalURL` in your Sourcegraph instance's Site Configuration to reflect that +> NOTE: If you have configured a DNS entry for the IP, please ensure to update `externalURL` in your Sourcegraph instance's Advanced Configuration to reflect that --- @@ -169,4 +169,4 @@ the old external Postgres service will get Sourcegraph back to its previous stat ## Other resources [HTTP and HTTPS/SSL configuration](/self-hosted/http-https-configuration#sourcegraph-via-docker-compose-caddy-2) -[Site Administration Quickstart](/admin/how-to/site-admin-quickstart) +[Administration Quickstart](/admin/how-to/site-admin-quickstart) diff --git a/docs/self-hosted/deploy/docker-compose/index.mdx b/docs/self-hosted/deploy/docker-compose/index.mdx index 61217be84..78e97c12e 100644 --- a/docs/self-hosted/deploy/docker-compose/index.mdx +++ b/docs/self-hosted/deploy/docker-compose/index.mdx @@ -190,4 +190,4 @@ Once the server is ready, navigate to the `sourcegraph-frontend-0` hostname or I - [Upgrade](/self-hosted/deploy/docker-compose/upgrade) - [Management Operations](/self-hosted/deploy/docker-compose/operations) - [HTTP and HTTPS/SSL configuration](/self-hosted/http-https-configuration#sourcegraph-via-docker-compose-caddy-2) -- [Site Administration Quickstart](/admin/how-to/site-admin-quickstart) +- [Administration Quickstart](/admin/how-to/site-admin-quickstart) diff --git a/docs/self-hosted/deploy/docker-compose/migrate.mdx b/docs/self-hosted/deploy/docker-compose/migrate.mdx index e79992170..4d03d326e 100644 --- a/docs/self-hosted/deploy/docker-compose/migrate.mdx +++ b/docs/self-hosted/deploy/docker-compose/migrate.mdx @@ -224,6 +224,6 @@ docker-compose -f docker-compose.yaml up -d The migration process is now complete. -You should be able to log into your instance and verify that previous users and configuration are still present. Repositories may take awhile to clone and index, but their names should be immediately visible in the site admin repositories list. Wait for repositories to clone and verify the new Sourcegraph instance works as expected. +You should be able to log into your instance and verify that previous users and configuration are still present. Repositories may take awhile to clone and index, but their names should be immediately visible in the Administration repositories list. Wait for repositories to clone and verify the new Sourcegraph instance works as expected. After verifying the new instance is functional, you can tear down the old `sourcegraph/server` single Docker container Sourcegraph instance. diff --git a/docs/self-hosted/deploy/docker-compose/upgrade.mdx b/docs/self-hosted/deploy/docker-compose/upgrade.mdx index 86ac84245..cb41e8452 100644 --- a/docs/self-hosted/deploy/docker-compose/upgrade.mdx +++ b/docs/self-hosted/deploy/docker-compose/upgrade.mdx @@ -77,7 +77,7 @@ To perform a multi-version upgrade via migrators [upgrade](/self-hosted/updates/ 1. **Check Upgrade Readiness**: - Check the [upgrade notes](https://sourcegraph.com/changelog/self-hosted/docker-compose) for the version range you're passing through. - - Check the `Site Admin > Updates` page to determine [upgrade readiness](/self-hosted/updates/#upgrade-readiness). + - Check the `Administration > Updates` page to determine [upgrade readiness](/self-hosted/updates/#upgrade-readiness). 2. **Pull and merge upstream changes**: diff --git a/docs/self-hosted/deploy/kubernetes/configure.mdx b/docs/self-hosted/deploy/kubernetes/configure.mdx index 08c40119a..b4aeab407 100644 --- a/docs/self-hosted/deploy/kubernetes/configure.mdx +++ b/docs/self-hosted/deploy/kubernetes/configure.mdx @@ -190,7 +190,7 @@ To enable tracing on your Kustomize instance, you'll need to either: 1. Deploy our bundled OpenTelemetry Collector with our bundled Jaeger backend, or 2. Deploy our bundled OpenTelemetry Collector and configure an external tracing backend -Once a tracing backend has been deployed, see our [Tracing](/self-hosted/observability/tracing) page for next steps, including required changes to your Site Configuration to enable traces. +Once a tracing backend has been deployed, see our [Tracing](/self-hosted/observability/tracing) page for next steps, including required changes to your Advanced Configuration to enable traces. ### Deploy the bundled OpenTelemetry Collector and Jaeger @@ -1177,7 +1177,7 @@ components: Sourcegraph's Kubernetes deployment [requires an Enterprise license key](https://about.sourcegraph.com/pricing). -Once you have a license key, add it to your [site configuration](/admin/config/site-config). +Once you have a license key, add it to your [advanced configuration](/admin/config/site-config). --- diff --git a/docs/self-hosted/deploy/kubernetes/index.mdx b/docs/self-hosted/deploy/kubernetes/index.mdx index b8e6dc7a8..54b5cba34 100644 --- a/docs/self-hosted/deploy/kubernetes/index.mdx +++ b/docs/self-hosted/deploy/kubernetes/index.mdx @@ -330,7 +330,7 @@ To enable tracing on your Helm instance, you'll need to either: 1. Deploy our bundled Jaeger backend, or 2. Configure an external tracing backend -Once a tracing backend has been deployed, see our [Tracing](/self-hosted/observability/tracing) page for next steps, including required changes to your Site Configuration to enable traces. +Once a tracing backend has been deployed, see our [Tracing](/self-hosted/observability/tracing) page for next steps, including required changes to your Advanced Configuration to enable traces. #### Enable the bundled Jaeger deployment @@ -1000,7 +1000,7 @@ When all pods have restarted and show as Running, you can browse to your Sourceg **Step 1:** Check Upgrade Readiness: - Check the [upgrade notes](https://sourcegraph.com/changelog/self-hosted/kubernetes) for the version range you're passing through. -- Check the `Site Admin > Updates` page to determine [upgrade readiness](/self-hosted/updates/#upgrade-readiness). +- Check the `Administration > Updates` page to determine [upgrade readiness](/self-hosted/updates/#upgrade-readiness). **Step 2:** diff --git a/docs/self-hosted/deploy/kubernetes/kustomize.mdx b/docs/self-hosted/deploy/kubernetes/kustomize.mdx index cfa8f9457..aeb4407b0 100644 --- a/docs/self-hosted/deploy/kubernetes/kustomize.mdx +++ b/docs/self-hosted/deploy/kubernetes/kustomize.mdx @@ -193,7 +193,7 @@ To verify that the deployment was successful, port-forward the frontend pod with $ kubectl port-forward svc/sourcegraph-frontend 3080:30080 ``` -Then access your new Sourcegraph instance at http://localhost:3080 to proceed to the site-admin setup step. +Then access your new Sourcegraph instance at http://localhost:3080 to proceed to the administrator setup step. ```bash $ open http://localhost:3080 diff --git a/docs/self-hosted/deploy/kubernetes/upgrade.mdx b/docs/self-hosted/deploy/kubernetes/upgrade.mdx index 6d9c31c97..7ac1347bc 100644 --- a/docs/self-hosted/deploy/kubernetes/upgrade.mdx +++ b/docs/self-hosted/deploy/kubernetes/upgrade.mdx @@ -87,7 +87,7 @@ To perform a multi-version upgrade via migrators [upgrade](/self-hosted/updates/ 1. **Check Upgrade Readiness**: - Check the [upgrade notes](https://sourcegraph.com/changelog/self-hosted/kubernetes) for the version range you're passing through. - - Check the `Site Admin > Updates` page to determine [upgrade readiness](/self-hosted/updates/#upgrade-readiness). + - Check the `Administration > Updates` page to determine [upgrade readiness](/self-hosted/updates/#upgrade-readiness). 2. **Pull and merge upstream changes**: diff --git a/docs/self-hosted/deploy/machine-images/aws-ami.mdx b/docs/self-hosted/deploy/machine-images/aws-ami.mdx index 7fbd5d40c..5a8b8b210 100644 --- a/docs/self-hosted/deploy/machine-images/aws-ami.mdx +++ b/docs/self-hosted/deploy/machine-images/aws-ami.mdx @@ -77,7 +77,7 @@ To enable executors you must do the following: helm upgrade -i -f ./override.yaml --version "$(cat /home/ec2-user/.sourcegraph-version)" executor ./sourcegraph-executor-k8s-charts.tgz ``` -1. Add the following to the site-admin config using the password you chose previously +1. Add the following to the advanced configuration using the password you chose previously ``` "executors.accessToken": "", @@ -85,7 +85,7 @@ helm upgrade -i -f ./override.yaml --version "$(cat /home/ec2-user/.sourcegraph- "codeIntelAutoIndexing.enabled": true ``` -1. Check `Site-Admin > Executors > Instances` to verify the executor connected successfully. If it does not appear try reboot the instance +1. Check `Administration > Executors > Instances` to verify the executor connected successfully. If it does not appear try reboot the instance To use server-side batch changes, see the [server-side batch changes documentation](/batch-changes/server-side). diff --git a/docs/self-hosted/deploy/machine-images/aws-oneclick.mdx b/docs/self-hosted/deploy/machine-images/aws-oneclick.mdx index 64c091aa9..61265575f 100644 --- a/docs/self-hosted/deploy/machine-images/aws-oneclick.mdx +++ b/docs/self-hosted/deploy/machine-images/aws-oneclick.mdx @@ -89,7 +89,7 @@ To enable executors you must do the following: helm upgrade -i -f ./override.yaml --version "$(cat /home/ec2-user/.sourcegraph-version)" executor sourcegraph/sourcegraph-executor-k8s ``` -1. Adding the following to the site-admin config using the password you chose previously +1. Adding the following to the advanced configuration using the password you chose previously ```curl "executors.accessToken": "", @@ -97,7 +97,7 @@ helm upgrade -i -f ./override.yaml --version "$(cat /home/ec2-user/.sourcegraph- "codeIntelAutoIndexing.enabled": true ``` -1. Check `Site-Admin > Executors > Instances` to verify the executor connected successfully. If it does not appear try reboot the instance +1. Check `Administration > Executors > Instances` to verify the executor connected successfully. If it does not appear try reboot the instance To use server-side batch changes, see the [server-side batch changes documentation](/batch-changes/server-side). diff --git a/docs/self-hosted/deploy/machine-images/gce.mdx b/docs/self-hosted/deploy/machine-images/gce.mdx index 0e4521554..34a1ef386 100644 --- a/docs/self-hosted/deploy/machine-images/gce.mdx +++ b/docs/self-hosted/deploy/machine-images/gce.mdx @@ -129,7 +129,7 @@ To enable executors you must do the following: helm upgrade -i -f ./override.yaml --version "$(cat /home/sourcegraph/.sourcegraph-version)" executor sourcegraph/sourcegraph-executor-k8s ``` -1. Add the following to the site-admin config using the password you chose previously: +1. Add the following to the advanced configuration using the password you chose previously: ``` "executors.accessToken": "", @@ -137,7 +137,7 @@ helm upgrade -i -f ./override.yaml --version "$(cat /home/sourcegraph/.sourcegra "codeIntelAutoIndexing.enabled": true ``` -1. Check `Site-Admin > Executors > Instances` to verify the executor connected successfully. If it does not appear try reboot the instance. +1. Check `Administration > Executors > Instances` to verify the executor connected successfully. If it does not appear try reboot the instance. To use server-side batch changes, see the [server-side batch changes documentation](/batch-changes/server-side). diff --git a/docs/self-hosted/deploy/migrate-backup.mdx b/docs/self-hosted/deploy/migrate-backup.mdx index 47781f765..658fc0516 100644 --- a/docs/self-hosted/deploy/migrate-backup.mdx +++ b/docs/self-hosted/deploy/migrate-backup.mdx @@ -18,7 +18,7 @@ These files are the most essential pieces of information required for a migratio | Data | Can it be recreated without a backup? | Notes | | --------------------------------------------------------------------------------- | ------------------------------------- | --------------------------------------------------------------------------------- | -| [Site configuration](/admin/config/site-config) | No | This file contains key configuration that defines how the product works. | +| [Advanced configuration](/admin/config/site-config) | No | This file contains key configuration that defines how the product works. | | [Code host connection configuration(s)](/admin/code-hosts/) | No | Each connection to an external code host has its own short configuration file. | | [Global settings](/admin/config/settings#editing-global-settings-for-site-admins) | No | Default settings can be set by administrators for all users by editing this file. | diff --git a/docs/self-hosted/deploy/scale.mdx b/docs/self-hosted/deploy/scale.mdx index 4ba657a1f..326d2892d 100644 --- a/docs/self-hosted/deploy/scale.mdx +++ b/docs/self-hosted/deploy/scale.mdx @@ -276,7 +276,7 @@ It is shipped with customized dashboards for Sourcegraph services. | Resources | | | :---------- | :---------------------------------------------------------- | | `Overview` | Not designed to be a high-traffic service | -| `Factors` | Number of Site Admins | +| `Factors` | Number of Administrators | | `Guideline` | The default setup should be sufficient for most deployments | --- @@ -290,7 +290,7 @@ A Jaeger instance for end-to-end distributed tracing | Resources | | | :---------- | :----------------------------------------------------------------------------------------------------- | | `Overview` | A debugging tool that is not designed to be a high-traffic service | -| `Factors` | Number of Site Admins | +| `Factors` | Number of Administrators | | `Guideline` | Memory depends on the size of buffers, like the number of traces and the size of the queue for example | diff --git a/docs/self-hosted/email.mdx b/docs/self-hosted/email.mdx index e976d313a..c647d0693 100644 --- a/docs/self-hosted/email.mdx +++ b/docs/self-hosted/email.mdx @@ -24,9 +24,9 @@ To verify their email address, the user can do one of the following: - Click the "set password" link they receive in their email - In the "Emails" tab of their account, click "Send verification email" -- Ask a site admin to verify their email manually through the "Emails" tab of their account, or through the `setUserEmailVerified` GraphQL mutation +- Ask an administrator to verify their email manually through the "Emails" tab of their account, or through the `setUserEmailVerified` GraphQL mutation -Users with emails [created by the site admin](/admin/auth/#creating-builtin-authentication-users) through the `/site-admin/users/new` UI will have the same behaviour as the above. Users created directly through GraphQL or the `src` CLI assume that the email provided is verified. +Users with emails [created by the administrator](/admin/auth/#creating-builtin-authentication-users) through the `/site-admin/users/new` UI will have the same behaviour as the above. Users created directly through GraphQL or the `src` CLI assume that the email provided is verified. For SSO (Single Sign-On) enabled instances, it is important to remove the @@ -44,7 +44,7 @@ Users with emails [created by the site admin](/admin/auth/#creating-builtin-auth To use Amazon SES with Sourcegraph, first [follow these steps to create an SES account for Sourcegraph](https://docs.aws.amazon.com/ses/latest/dg/send-email-smtp-software-package.html). -Navigate to your site configuration (e.g. `https://sourcegraph.com/site-admin/configuration`) and fill in the configuration: +Navigate to your advanced configuration (e.g. `https://sourcegraph.com/site-admin/configuration`) and fill in the configuration: ```jsonc { @@ -69,7 +69,7 @@ Please note that the configured `email.address` (the from address) must be a ver To use Google Workspace with Sourcegraph, you will need to [create an SMTP Relay account](https://support.google.com/a/answer/2956491). Be sure to choose `Require SMTP Authentication` and `Require TLS encryption` in step 7. -Navigate to your site configuration (e.g. `https://sourcegraph.com/site-admin/configuration`) and fill in the configuration: +Navigate to your advanced configuration (e.g. `https://sourcegraph.com/site-admin/configuration`) and fill in the configuration: ```jsonc { @@ -98,7 +98,7 @@ Other providers such as Mailchimp and Sendgrid may also be used with Sourcegraph - https://mailchimp.com/developer/transactional/docs/smtp-integration/ - https://docs.sendgrid.com/for-developers/sending-email/getting-started-smtp -Once you have an SMTP account, simply navigate to your site configuration (e.g. `https://sourcegraph.com/site-admin/configuration`) and fill in the configuration: +Once you have an SMTP account, simply navigate to your advanced configuration (e.g. `https://sourcegraph.com/site-admin/configuration`) and fill in the configuration: ```jsonc { @@ -161,7 +161,7 @@ If you need further assistance, please let us know at `mailto:support@sourcegrap Customize email templates sent by Sourcegraph via the `email.templates` configuration option. -Navigate to your site configuration (e.g. `https://sourcegraph.com/site-admin/configuration`) and add: +Navigate to your advanced configuration (e.g. `https://sourcegraph.com/site-admin/configuration`) and add: ```jsonc { diff --git a/docs/self-hosted/encryption.mdx b/docs/self-hosted/encryption.mdx index ef7597033..34aef4e6c 100644 --- a/docs/self-hosted/encryption.mdx +++ b/docs/self-hosted/encryption.mdx @@ -12,7 +12,7 @@ Currently supported encryption backends: To enable encryption you must specify a key config for each of the keys defined in `encryption.keys` that you wish to encrypt. You can specify the same key for all keys if you choose to, but you must at least specify config for all of them. -When you first enable encryption, new records will be written to the database as encrypted, but existing data will initially be unencrypted. Existing unencrypted records will be encrypted in the background over time. The status of this job can be checked via the `Worker > Record encrypter` dashboard in Grafana, and under **Site-admin > Background jobs**, the name of this job is **record-encrypter**. +When you first enable encryption, new records will be written to the database as encrypted, but existing data will initially be unencrypted. Existing unencrypted records will be encrypted in the background over time. The status of this job can be checked via the `Worker > Record encrypter` dashboard in Grafana, and under **Administration > Background jobs**, the name of this job is **record-encrypter**. We distinguish encrypted and unencrypted records in the database, so partially encrypted/decrypted databases are readable by the application, so enabling or disabling encryption should not impact performance or data integrity of your instance. @@ -46,7 +46,7 @@ We distinguish encrypted and unencrypted records in the database, so partially e ## Disabling -If you decide to disable encryption, or want to switch to a new key, you must first decrypt the database. To do so, set the environment variable `ALLOW_DECRYPTION` to `true` on the `frontend` and `worker` services. New records will be written to the database as plaintext. Existing encrypted records will be decrypted in the background over time. The status of this job can be checked the same way as enabling the initial encryption job, via the `Worker > Record encrypter` dashboard in Grafana. Once all existing records have been decrypted, the existing keys can be removed from the site configuration. +If you decide to disable encryption, or want to switch to a new key, you must first decrypt the database. To do so, set the environment variable `ALLOW_DECRYPTION` to `true` on the `frontend` and `worker` services. New records will be written to the database as plaintext. Existing encrypted records will be decrypted in the background over time. The status of this job can be checked the same way as enabling the initial encryption job, via the `Worker > Record encrypter` dashboard in Grafana. Once all existing records have been decrypted, the existing keys can be removed from the advanced configuration. ## Key rotation diff --git a/docs/self-hosted/executors/deploy-executors-binary-offline.mdx b/docs/self-hosted/executors/deploy-executors-binary-offline.mdx index 96cf75cb3..50bf87d4a 100644 --- a/docs/self-hosted/executors/deploy-executors-binary-offline.mdx +++ b/docs/self-hosted/executors/deploy-executors-binary-offline.mdx @@ -81,7 +81,7 @@ Auto Indexing requires images to be available in the internal Docker Registry. T the [Code Navigation](/code-navigation) page. Once the images are available in the internal Docker Registry, the `executor` can be configured to use the images by -updating `codeIntelAutoIndexing.indexerMap` in the **Site configuration**. For example, +updating `codeIntelAutoIndexing.indexerMap` in the **Advanced configuration**. For example, ```json "codeIntelAutoIndexing.indexerMap": { diff --git a/docs/self-hosted/executors/deploy-executors-binary.mdx b/docs/self-hosted/executors/deploy-executors-binary.mdx index 257c3bb2c..8821b1f9a 100644 --- a/docs/self-hosted/executors/deploy-executors-binary.mdx +++ b/docs/self-hosted/executors/deploy-executors-binary.mdx @@ -237,7 +237,7 @@ systemctl start executor systemctl status executor ``` -Otherwise, run `executor run` directly. Your executor should start listening for jobs and be visible under **Site admin > Executors > Instances**. +Otherwise, run `executor run` directly. Your executor should start listening for jobs and be visible under **Administration > Executors > Instances**. ## Related configuration diff --git a/docs/self-hosted/executors/deploy-executors-dind.mdx b/docs/self-hosted/executors/deploy-executors-dind.mdx index cf5b58c3e..0617b6cdf 100644 --- a/docs/self-hosted/executors/deploy-executors-dind.mdx +++ b/docs/self-hosted/executors/deploy-executors-dind.mdx @@ -32,7 +32,7 @@ The executor and a Docker-in-Docker daemon run as containers in the same Kuberne Before deploying, ensure your Sourcegraph instance is configured to accept executor connections. See [Setting up executors](/admin/executors#setting-up-executors) for instructions on - setting the required `executors.accessToken` in your site configuration. + setting the required `executors.accessToken` in your advanced configuration. Ensure you have the following tools installed: @@ -71,7 +71,7 @@ To specifically deploy Executors, ```bash helm upgrade --install --values ./override.yaml --version sg-executor sourcegraph/sourcegraph-executor-dind ``` -3. Confirm executors are working by checking the _Executors_ page under **Site admin > Executors > Instances**. +3. Confirm executors are working by checking the _Executors_ page under **Administration > Executors > Instances**. #### Deployment via Kustomize @@ -101,7 +101,7 @@ Upgrading Docker-in-Docker executors follows the same pattern as the initial dep kubectl get pods -l app.kubernetes.io/component=executor ``` -4. Confirm the executor is online and reporting the expected version under **Site admin > Executors > Instances**. +4. Confirm the executor is online and reporting the expected version under **Administration > Executors > Instances**. ### Kustomize @@ -112,7 +112,7 @@ Upgrading Docker-in-Docker executors follows the same pattern as the initial dep kubectl apply --prune -l deploy=sourcegraph -f ``` -3. Confirm the executor is online under **Site admin > Executors > Instances**. +3. Confirm the executor is online under **Administration > Executors > Instances**. ## Security considerations diff --git a/docs/self-hosted/executors/deploy-executors-docker.mdx b/docs/self-hosted/executors/deploy-executors-docker.mdx index babf16d55..c1496216a 100644 --- a/docs/self-hosted/executors/deploy-executors-docker.mdx +++ b/docs/self-hosted/executors/deploy-executors-docker.mdx @@ -76,7 +76,7 @@ Upgrading Docker Compose executors requires updating the executor image tag in t docker ps --filter name=executor --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}' ``` -4. Confirm the executor is online and reporting the expected version under **Site admin > Executors > Instances**. +4. Confirm the executor is online and reporting the expected version under **Administration > Executors > Instances**. ## Related configuration diff --git a/docs/self-hosted/executors/deploy-executors-kubernetes.mdx b/docs/self-hosted/executors/deploy-executors-kubernetes.mdx index c185704bf..096578c06 100644 --- a/docs/self-hosted/executors/deploy-executors-kubernetes.mdx +++ b/docs/self-hosted/executors/deploy-executors-kubernetes.mdx @@ -80,14 +80,14 @@ Native Kubernetes Executors can be deployed via either the `sourcegraph-executor ### Steps -1. If you are deploying Executors for processing Batch Changes, set `batchChanges.nativeServerSideExecution` to `true` in your [site configuration](/admin/config/site-config). Only enable this when using Executors on Kubernetes. +1. If you are deploying Executors for processing Batch Changes, set `batchChanges.nativeServerSideExecution` to `true` in your [advanced configuration](/admin/config/site-config). Only enable this when using Executors on Kubernetes. > **Note:** Batch Changes on native Kubernetes executors inherits the beta limitations of > the native Kubernetes runtime. See the warning at the top of this page. 2. Configure the following environment variables on the Executor Deployment: 1. `EXECUTOR_FRONTEND_URL` should match the URL of your Sourcegraph instance - 2. `EXECUTOR_FRONTEND_PASSWORD` should match the `executors.accessToken` key in the Sourcegraph instance's site configuration + 2. `EXECUTOR_FRONTEND_PASSWORD` should match the `executors.accessToken` key in the Sourcegraph instance's advanced configuration 3. Either `EXECUTOR_QUEUE_NAMES` or `EXECUTOR_QUEUE_NAME` should be set to the [queues](/self-hosted/executors/executors-config#queues) the Executor will serve. Executors that process batch changes should serve `batches,batches-hooks`; executors for precise auto-indexing serve `codeintel`. 4. `EXECUTOR_KUBERNETES_NAMESPACE` should be set to the Kubernetes namespace where you intend to run the worker pods. This should generally match the namespace where you deploy the Executor resources in the next step. @@ -100,7 +100,7 @@ Native Kubernetes Executors can be deployed via either the `sourcegraph-executor 3. Deploy the native Kubernetes Executor resources to your Kubernetes cluster via either the `sourcegraph-executor-k8s` [Helm chart](https://github.com/sourcegraph/deploy-sourcegraph-helm/tree/main/charts/sourcegraph-executor/k8s) or the `executors/k8s` [Kustomize component](https://github.com/sourcegraph/deploy-sourcegraph-k8s/tree/main/components/executors/k8s). 1. For more details on how to work with the Sourcegraph Helm chart, see the [Helm chart docs](/self-hosted/deploy/kubernetes#configuration) (_Note: The same Helm values `override.yaml` file can be used for both the main `sourcegraph` Helm chart as well as the `sourcegraph-executor-k8s` chart_) 2. For more details on how to configure the `executors/k8s` component for your Kustomize deployment, see the [Kustomize configuration docs](/self-hosted/deploy/kubernetes/configure#overview) -4. Once all the native Kubernetes Executor resources have been deployed to your cluster, confirm that the Executors are online by checking the _Executors_ page under **Site admin > Executors > Instances** +4. Once all the native Kubernetes Executor resources have been deployed to your cluster, confirm that the Executors are online by checking the _Executors_ page under **Administration > Executors > Instances** ## Upgrading executors @@ -126,7 +126,7 @@ Upgrading native Kubernetes executors follows the same pattern as the initial de kubectl get pods -l app.kubernetes.io/component=executor ``` -4. Confirm the executor is online and reporting the expected version under **Site admin > Executors > Instances**. +4. Confirm the executor is online and reporting the expected version under **Administration > Executors > Instances**. ### Kustomize @@ -137,7 +137,7 @@ Upgrading native Kubernetes executors follows the same pattern as the initial de kubectl apply --prune -l deploy=sourcegraph -f ``` -3. Confirm the executor is online under **Site admin > Executors > Instances**. +3. Confirm the executor is online under **Administration > Executors > Instances**. ## Additional Notes diff --git a/docs/self-hosted/executors/deploy-executors-terraform-aws.mdx b/docs/self-hosted/executors/deploy-executors-terraform-aws.mdx index 9d032f450..c5a02ff6b 100644 --- a/docs/self-hosted/executors/deploy-executors-terraform-aws.mdx +++ b/docs/self-hosted/executors/deploy-executors-terraform-aws.mdx @@ -51,8 +51,8 @@ module "executors" { | Variable | Description | | ---------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `availability_zone` | The AWS availability zone to create the instance in. | -| `executor_sourcegraph_external_url` | The public URL of your Sourcegraph instance. This corresponds to the `externalURL` value in your Sourcegraph instance's site configuration and must be resolvable from the provisioned executor compute resources. | -| `executor_sourcegraph_executor_proxy_password` | The access token corresponding to the `executors.accessToken` in your Sourcegraph instance's site configuration. | +| `executor_sourcegraph_external_url` | The public URL of your Sourcegraph instance. This corresponds to the `externalURL` value in your Sourcegraph instance's advanced configuration and must be resolvable from the provisioned executor compute resources. | +| `executor_sourcegraph_executor_proxy_password` | The access token corresponding to the `executors.accessToken` in your Sourcegraph instance's advanced configuration. | | `executor_queue_name` | The single [queue](/self-hosted/executors/executors-config#queues) from which the executor should pull jobs. Either this or `executor_queue_names` must be set. | | `executor_queue_names` | The [queues](/self-hosted/executors/executors-config#queues) from which the executor should pull jobs. Executors serving batch changes need both `batches` and `batches-hooks`. Either this or `executor_queue_name` must be set. | | `executor_instance_tag` | A label tag to add to all the executors; can be used for filtering out the right instances in monitoring. | @@ -133,11 +133,11 @@ The following is a step-by-step guide on provisioning a single `codeintel` execu 1. [Install Terraform](#terraform-version). 2. Install the [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). 3. Run `aws configure` to set up your credentials and default region. -4. Set up your Sourcegraph instance's Site configuration for executors +4. Set up your Sourcegraph instance's Advanced configuration for executors 1. Click on your profile picture in the top right corner - 2. Select **Site admin** + 2. Select **Administration** 3. Expand the **Configuration** section - 4. Select **Site configuration** + 4. Select **Advanced configuration** 5. Set the following, - `"externalURL": "https://sourcegraph.example.com"` - Replace with a URL that is accessible from the EC2 instance @@ -151,13 +151,13 @@ The following is a step-by-step guide on provisioning a single `codeintel` execu - `region` to the AWS region to provision the executor in 7. Change the following in `main.tf` - `availability_zone` to an availability zone within your chosen region (e.g. `us-west-2a`) - - `executor_sourcegraph_external_url` to the URL configured in your instance's **Site configuration** - - `executor_sourcegraph_executor_proxy_password` to the access token configured in your instance's **Site configuration** + - `executor_sourcegraph_external_url` to the URL configured in your instance's **Advanced configuration** + - `executor_sourcegraph_executor_proxy_password` to the access token configured in your instance's **Advanced configuration** 8. Run `terraform init` to download the Sourcegraph executor modules. 9. Run `terraform plan` to preview the changes that will occur to your AWS infrastructure. 10. Run `terraform apply` and enter "yes" after reviewing the proposed changes to create the executor resources. - Ensure `terraform apply` exited with code 0 and did not print any errors -11. Go back to the site admin page, expand **Executors**, click **Instances**, and check to see if your executor shows up in the list with a green dot 🟢 +11. Go back to the Administration page, expand **Executors**, click **Instances**, and check to see if your executor shows up in the list with a green dot 🟢 ### Validation @@ -214,7 +214,7 @@ ubuntu@ip-10-0-1-42:~$ curl https://sourcegraph.example.com ### Configure Auto-indexing -1. Go to the **Site admin** page +1. Go to the **Administration** page 2. Expand **Code graph**, 3. Select **Configuration** 4. Click **Create new policy**, and fill in: diff --git a/docs/self-hosted/executors/deploy-executors-terraform-gcp.mdx b/docs/self-hosted/executors/deploy-executors-terraform-gcp.mdx index 60ada84d3..5da1af950 100644 --- a/docs/self-hosted/executors/deploy-executors-terraform-gcp.mdx +++ b/docs/self-hosted/executors/deploy-executors-terraform-gcp.mdx @@ -53,8 +53,8 @@ module "executors" { | ---------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `region` | The Google Cloud region to provision the executor resources in. | | `zone` | The Google Cloud zone to provision the executor resources in. | -| `executor_sourcegraph_external_url` | The public URL of your Sourcegraph instance. This corresponds to the `externalURL` value in your Sourcegraph instance's site configuration and must be resolvable from the provisioned executor compute resources. | -| `executor_sourcegraph_executor_proxy_password` | The access token corresponding to the `executors.accessToken` in your Sourcegraph instance's site configuration. | +| `executor_sourcegraph_external_url` | The public URL of your Sourcegraph instance. This corresponds to the `externalURL` value in your Sourcegraph instance's advanced configuration and must be resolvable from the provisioned executor compute resources. | +| `executor_sourcegraph_executor_proxy_password` | The access token corresponding to the `executors.accessToken` in your Sourcegraph instance's advanced configuration. | | `executor_queue_name` | The single [queue](/self-hosted/executors/executors-config#queues) from which the executor should pull jobs. Either this or `executor_queue_names` must be set. | | `executor_queue_names` | The [queues](/self-hosted/executors/executors-config#queues) from which the executor should pull jobs. Executors serving batch changes need both `batches` and `batches-hooks`. Either this or `executor_queue_name` must be set. | | `executor_instance_tag` | A label tag to add to all the executors; can be used for filtering out the right instances in stackdriver monitoring. | @@ -149,11 +149,11 @@ The following is a step-by-step guide on provisioning a single `codeintel` execu 1. [Install Terraform](#terraform-version). 2. Install the [`gcloud CLI`](https://cloud.google.com/sdk/docs/install) 3. Run `gcloud auth application-default login` -4. Set up your Sourcegraph instance's Site configuration for executors +4. Set up your Sourcegraph instance's Advanced configuration for executors 1. Click on your profile picture in the top right corner - 2. Select **Site admin** + 2. Select **Administration** 3. Expand the **Configuration** section - 4. Select **Site configuration** + 4. Select **Advanced configuration** 5. Set the following, - `"externalURL": "https://sourcegraph.example.com"` - Replace with a URL that is accessible from the GCP VM @@ -169,14 +169,14 @@ The following is a step-by-step guide on provisioning a single `codeintel` execu - `region` to the GCP region to provision the executor in - `zone` to the GCP zone to provision the executor in 7. Change the following in `main.tf` - - `executor_sourcegraph_external_url` to the URL configured in your instance's **Site configuration** + - `executor_sourcegraph_external_url` to the URL configured in your instance's **Advanced configuration** - `executor_sourcegraph_executor_proxy_password` to the access token configured in your instance's **Site configuration** 8. Run `terraform init` to download the Sourcegraph executor modules. 9. Run `terraform plan` to preview the changes that will occur to your GCP infrastructure. 10. Run `terraform apply` and enter "yes" after reviewing the proposed changes to create the executor VM - Ensure `terraform apply` exited with code 0 and did not print any errors -11. Go back to the site admin page, expand **Executors**, click **Instances**, and check to see if your executor shows +11. Go back to the Administration page, expand **Executors**, click **Instances**, and check to see if your executor shows up in the list with a green dot 🟢 ### Validation @@ -235,7 +235,7 @@ you@sourcegraph-executor-h0rv:~$ curl https://sourcegraph.example.com ### Configure Auto-indexing -1. Go to the **Site admin** page +1. Go to the **Administration** page 2. Expand **Code graph**, 3. Select **Configuration** 4. Click **Create new policy**, and fill in: diff --git a/docs/self-hosted/executors/executors-config.mdx b/docs/self-hosted/executors/executors-config.mdx index a5c685291..7951ecc88 100644 --- a/docs/self-hosted/executors/executors-config.mdx +++ b/docs/self-hosted/executors/executors-config.mdx @@ -26,7 +26,7 @@ An executor that should handle every job type uses `EXECUTOR_QUEUE_NAMES=batches | Configuration Key | Description | Example value | | ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------ | | `EXECUTOR_FRONTEND_URL` | The external URL of the Sourcegraph instance. **required** | `https://sourcegraph.example.com` | -| `EXECUTOR_FRONTEND_PASSWORD` | The shared secret configured in the Sourcegraph instance site config under `executors.accessToken`. **required** | `our-shared-secret` | +| `EXECUTOR_FRONTEND_PASSWORD` | The shared secret configured in the Sourcegraph instance advanced configuration under `executors.accessToken`. **required** | `our-shared-secret` | | `EXECUTOR_QUEUE_NAME` | The name of a single queue to pull jobs from. See [Queues](#queues) for possible values. **required: either this or `EXECUTOR_QUEUE_NAMES`** | `codeintel` | | `EXECUTOR_QUEUE_NAMES` | The names of multiple queues to pull jobs from, comma-separated. See [Queues](#queues) for possible values. **required: either this or `EXECUTOR_QUEUE_NAME`** | `batches,batches-hooks` | | `EXECUTOR_USE_FIRECRACKER` | Whether to isolate jobs in virtual machines. Requires ignite and firecracker. Linux hosts only. Kubernetes is not supported. (default value: "true" when OS is Linux and not on Kubernetes) | `true` | diff --git a/docs/self-hosted/executors/executors-troubleshooting.mdx b/docs/self-hosted/executors/executors-troubleshooting.mdx index 490baa461..6a85ddfd1 100644 --- a/docs/self-hosted/executors/executors-troubleshooting.mdx +++ b/docs/self-hosted/executors/executors-troubleshooting.mdx @@ -173,7 +173,7 @@ This section lists some common mistakes with environment variables. Some of thes | Env var | Common mistakes | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | `EXECUTOR_FRONTEND_URL` | No protocol included (e.g. `https://` | -| `EXECUTOR_FRONTEND_PASSWORD` | Not set in `executor.accessToken` in the site config | +| `EXECUTOR_FRONTEND_PASSWORD` | Not set in `executor.accessToken` in the advanced configuration | | `EXECUTOR_QUEUE_NAME` | Value doesn't match one of the [valid queues](/self-hosted/executors/executors-config#queues), or neither of `EXECUTOR_QUEUE_NAME` and `EXECUTOR_QUEUE_NAMES` is set | | `EXECUTOR_QUEUE_NAMES` | A value doesn't match one of the [valid queues](/self-hosted/executors/executors-config#queues), or `batches` is set without `batches-hooks` so hook automations never run | |
  • `EXECUTOR_MAXIMUM_RUNTIME_PER_JOB`
  • `EXECUTOR_MAX_ACTIVE_TIME`
  • `EXECUTOR_QUEUE_POLL_INTERVAL`
  • `EXECUTOR_CLEANUP_TASK_INTERVAL`
| Value format can't be parsed by `time.ParseDuration` | diff --git a/docs/self-hosted/executors/index.mdx b/docs/self-hosted/executors/index.mdx index 2ced1350a..76eacfc17 100644 --- a/docs/self-hosted/executors/index.mdx +++ b/docs/self-hosted/executors/index.mdx @@ -86,9 +86,9 @@ The primary decision is whether jobs require a virtual-machine isolation boundar ## Validating executor deployments -Follow the validation steps in the guide for your selected deployment method. After the executor starts, confirm that it is active and reporting the expected version under **Site admin > Maintenance > Executor instances**. +Follow the validation steps in the guide for your selected deployment method. After the executor starts, confirm that it is active and reporting the expected version under **Administration > Maintenance > Executor instances**. -![Executor instances listed in the Sourcegraph site administration UI](https://storage.googleapis.com/sourcegraph-assets/docs/images/code-intelligence/sg-3.34/executor-ui-test.png) +![Executor instances listed in the Sourcegraph Administration UI](https://storage.googleapis.com/sourcegraph-assets/docs/images/code-intelligence/sg-3.34/executor-ui-test.png) ## Configure and operate executors diff --git a/docs/self-hosted/how-to/monitoring-guide.mdx b/docs/self-hosted/how-to/monitoring-guide.mdx index e4bf57f59..7a5b9d2d2 100644 --- a/docs/self-hosted/how-to/monitoring-guide.mdx +++ b/docs/self-hosted/how-to/monitoring-guide.mdx @@ -4,7 +4,7 @@ Please visit our [Observability Docs](/self-hosted/observability) for more in-de ## Prerequisites -This document assumes that you are a [site admin](/admin/). +This document assumes that you are a [administrator](/admin/). ## Set up monitoring diff --git a/docs/self-hosted/how-to/run-psql.mdx b/docs/self-hosted/how-to/run-psql.mdx index 6524e8d44..f5c2827ba 100644 --- a/docs/self-hosted/how-to/run-psql.mdx +++ b/docs/self-hosted/how-to/run-psql.mdx @@ -4,7 +4,7 @@ This document will take you through how to run postgres queries in the main data ## Prerequisites -- This document assumes that you are the site admin and have access to your Sourcegraph instance +- This document assumes that you are the administrator and have access to your Sourcegraph instance ## Kubernetes diff --git a/docs/self-hosted/how-to/setup-https.mdx b/docs/self-hosted/how-to/setup-https.mdx index bc9f30126..f02fe19c4 100644 --- a/docs/self-hosted/how-to/setup-https.mdx +++ b/docs/self-hosted/how-to/setup-https.mdx @@ -138,11 +138,13 @@ TLS_INGRESS_CLASS_NAME=nginx TLS_CLUSTER_ISSUER=letsencrypt-prod ``` -## Step 4: Update Site Configuration + -After configuring TLS, update your Sourcegraph site configuration to use HTTPS: +## Step 4: Update Advanced Configuration -1. Navigate to **Site admin > Configuration** +After configuring TLS, update your Sourcegraph advanced configuration to use HTTPS: + +1. Navigate to **Administration > Configuration** 2. Update the `externalURL` setting: ```json diff --git a/docs/self-hosted/how-to/troubleshoot-pod-eviction.mdx b/docs/self-hosted/how-to/troubleshoot-pod-eviction.mdx index 22782f6e5..d93a52a59 100644 --- a/docs/self-hosted/how-to/troubleshoot-pod-eviction.mdx +++ b/docs/self-hosted/how-to/troubleshoot-pod-eviction.mdx @@ -6,7 +6,7 @@ This document will take you step-by-step through the tasks required to perform t ## Prerequisites -This document assumes that you have deployed Sourcegraph on Kubernetes and you are a site admin for your organization. +This document assumes that you have deployed Sourcegraph on Kubernetes and you are an administrator for your organization. ## Steps to troubleshoot diff --git a/docs/self-hosted/how-to/unfinished-migration.mdx b/docs/self-hosted/how-to/unfinished-migration.mdx index abd5e86fb..bcda2e700 100644 --- a/docs/self-hosted/how-to/unfinished-migration.mdx +++ b/docs/self-hosted/how-to/unfinished-migration.mdx @@ -25,7 +25,7 @@ As an emergency escape hatch, the environment variable `SRC_DISABLE_OOBMIGRATION ## Checking progress -Progress of out-of-band migrations can be checked via the UI. Navigate to the `Site Admin > Maintenance > Migrations` page to see an overview of progress and errors of each active out-of-band migration. +Progress of out-of-band migrations can be checked via the UI. Navigate to the `Administration > Maintenance > Migrations` page to see an overview of progress and errors of each active out-of-band migration. ![Unfinished migration warning](https://storage.googleapis.com/sourcegraph-assets/oobmigration-warning-4.0.png) diff --git a/docs/self-hosted/http-https-configuration.mdx b/docs/self-hosted/http-https-configuration.mdx index 2681a4115..e512ac6e1 100644 --- a/docs/self-hosted/http-https-configuration.mdx +++ b/docs/self-hosted/http-https-configuration.mdx @@ -122,7 +122,7 @@ more details. ### Redirect to external HTTPS URL -The URL that clients should use to access Sourcegraph is defined in the `externalURL` property in [site configuration](/admin/config/site-config). To enforce that clients access Sourcegraph via this URL (and not some other URL, such as an IP address or other non-`https` URL), add the following to `nginx.conf` (replacing `https://sourcegraph.example.com` with your external URL): +The URL that clients should use to access Sourcegraph is defined in the `externalURL` property in [advanced configuration](/admin/config/site-config). To enforce that clients access Sourcegraph via this URL (and not some other URL, such as an IP address or other non-`https` URL), add the following to `nginx.conf` (replacing `https://sourcegraph.example.com` with your external URL): ```nginx # Redirect non-HTTPS traffic to HTTPS. @@ -152,7 +152,7 @@ See the [NGINX SSL Termination](https://docs.nginx.com/nginx/admin-guide/securit ### Next steps -You should configure Sourcegraph's `externalURL` in the [site configuration](/admin/config/site-config) (and restart the frontend instances) so that Sourcegraph knows its URL. +You should configure Sourcegraph's `externalURL` in the [advanced configuration](/admin/config/site-config) (and restart the frontend instances) so that Sourcegraph knows its URL. ## Sourcegraph via Docker Compose: Caddy 2 diff --git a/docs/self-hosted/index.mdx b/docs/self-hosted/index.mdx index 368a30459..28e756821 100644 --- a/docs/self-hosted/index.mdx +++ b/docs/self-hosted/index.mdx @@ -10,7 +10,7 @@ seoPriority: 1.0 This section of the documentation is meant for Sourcegraph enterprise self-hosted users. -Sourcegraph administration is primarily managed by site administrators, who are responsible for the deployment, management, and configuration of Sourcegraph instances for end users. For a comprehensive introduction to site administration, refer to our [quickstart guide](/admin/how-to/site-admin-quickstart). +Sourcegraph administration is primarily managed by administrators, who are responsible for the deployment, management, and configuration of Sourcegraph instances for end users. For a comprehensive introduction to administration, refer to our [quickstart guide](/admin/how-to/site-admin-quickstart). ## [Deploy Sourcegraph](/self-hosted/deploy/) diff --git a/docs/self-hosted/observability/alerting.mdx b/docs/self-hosted/observability/alerting.mdx index d37f8e477..a0b5a115d 100644 --- a/docs/self-hosted/observability/alerting.mdx +++ b/docs/self-hosted/observability/alerting.mdx @@ -1,6 +1,6 @@ # Alerting -Alerts can be configured to notify site admins when there is something wrong or noteworthy on the Sourcegraph instance. +Alerts can be configured to notify administrators when there is something wrong or noteworthy on the Sourcegraph instance. > NOTE: Alerting is not configurable for Sourcegraph Cloud instances; these instances have monitoring and alerting configured to notify the Sourcegraph team. @@ -21,7 +21,7 @@ Alerts fall in one of two severity levels: across many Sourcegraph deployments, they will also be promoted to critical alerts in an update by Sourcegraph. - **Examples:** High latency, high search timeouts, gitserver volume 80% full. - **Suggested action:** Email a - site administrator to investigate and monitor when convenient, and please + administrator to investigate and monitor when convenient, and please let us know so that we can improve them. Refer to the [alert solutions reference](/self-hosted/observability/alerts) for a complete list of Sourcegraph alerts, as well as possible solutions when these alerts are firing. @@ -29,7 +29,7 @@ Learn more about metrics, dashboards, and alert labels in our [metrics guide](/s ## Setting up alerting -Visit your site configuration (e.g. `https://sourcegraph.example.com/site-admin/configuration`) to configure alerts using the [`observability.alerts`](/admin/config/site-config#observability-alerts) field. As always, you can use `Ctrl+Space` at any time to get hints about allowed fields as well as relevant documentation inside the configuration editor. +Visit your advanced configuration (e.g. `https://sourcegraph.example.com/site-admin/configuration`) to configure alerts using the [`observability.alerts`](/admin/config/site-config#observability-alerts) field. As always, you can use `Ctrl+Space` at any time to get hints about allowed fields as well as relevant documentation inside the configuration editor. Once configured, Sourcegraph alerts will automatically be routed to the appropriate notification channels by severity level. @@ -181,7 +181,7 @@ For the complete set of fields, please refer to the [Alertmanager webhook docume #### Email -Note that to receive email notifications, the [`email.address`](/admin/config/site-config#email-address) and [`email.smtp`](/admin/config/site-config#email-smtp) fields must be configured in site configuration. +Note that to receive email notifications, the [`email.address`](/admin/config/site-config#email-address) and [`email.smtp`](/admin/config/site-config#email-smtp) fields must be configured in advanced configuration. ```json "observability.alerts": [ diff --git a/docs/self-hosted/observability/metrics.mdx b/docs/self-hosted/observability/metrics.mdx index f4a30870f..f11e2f2d8 100644 --- a/docs/self-hosted/observability/metrics.mdx +++ b/docs/self-hosted/observability/metrics.mdx @@ -4,9 +4,9 @@ Sourcegraph ships with [Grafana](https://grafana.com) for dashboards, [Prometheu ## Grafana -Site admins can view the Grafana monitoring dashboards on a Sourcegraph instance: +Administrators can view the Grafana monitoring dashboards on a Sourcegraph instance: -1. Go to **User menu > Site admin**. +1. Go to **User menu > Administration**. 1. Open the **Monitoring** page from the link in the left sidebar. The URL is `https://sourcegraph.example.com/-/debug/grafana/`. ![Sourcegraph dashboard](https://user-images.githubusercontent.com/3173176/82078081-65c62780-9695-11ea-954a-84e8e9686970.png) @@ -63,7 +63,7 @@ Changes to files in that directory will be detected automatically while Grafana More behavior can be controlled with [environmental variables](https://grafana.com/docs/grafana/latest/administration/configuration/#configure-with-environment-variables). -> As a workaround, site admins can [connect to Grafana directly](#accessing-grafana-directly) to make changes using the Grafana UI. +> As a workaround, administrators can [connect to Grafana directly](#accessing-grafana-directly) to make changes using the Grafana UI. ### Accessing Grafana directly @@ -186,7 +186,7 @@ The environment variable `PROMETHEUS_ADDITIONAL_FLAGS` can be used to pass on ad ### Accessing Prometheus directly -Most of the time, Sourcegraph site admins will monitor and query key metrics through [Grafana](#grafana), rather than through Prometheus directly. +Most of the time, Sourcegraph administrators will monitor and query key metrics through [Grafana](#grafana), rather than through Prometheus directly. Grafana also provides the dashboards that monitor the standard metrics that indicate the health of the instance. Follow the instructions below to access Prometheus directly instead. diff --git a/docs/self-hosted/observability/tracing.mdx b/docs/self-hosted/observability/tracing.mdx index e22c8403e..ccf53d441 100644 --- a/docs/self-hosted/observability/tracing.mdx +++ b/docs/self-hosted/observability/tracing.mdx @@ -6,7 +6,7 @@ To enable traces on your Sourcegraph Instance: 1. Deploy and / or configure a tracing backend -2. Configure tracing in your Site Configuration settings, to match your tracing backend +2. Configure tracing in your Advanced Configuration settings, to match your tracing backend ## Backends @@ -22,7 +22,7 @@ To deploy our bundled Jaeger backend, follow the instructions for your deploymen For Helm deployments, you can also [customize the Jaeger configuration](/self-hosted/deploy/kubernetes#customize-jaeger-configuration) (e.g., `max_traces`, sampling, log level) directly through Helm values. -Then configure your Site Configuration: +Then configure your Advanced Configuration: 1. Ensure your `externalURL` is configured 2. Configure `observability.tracing` > `urlTemplate` @@ -42,7 +42,7 @@ Then configure your Site Configuration: Where: -- `{{ .ExternalURL }}` is the value of the `externalURL` setting in your Sourcegraph instance's Site Configuration +- `{{ .ExternalURL }}` is the value of the `externalURL` setting in your Sourcegraph instance's Advanced Configuration - `{{ .TraceID }}` is the TraceID which gets generated while processing the request Once deployed, the Jaeger web UI will be accessible at `/-/debug/jaeger` @@ -51,12 +51,12 @@ Once deployed, the Jaeger web UI will be accessible at `/-/debug/jaeger` If you prefer to use an external, OTEL-compatible platform, you can configure Sourcegraph to export traces to it instead. See our [OpenTelemetry documentation](/self-hosted/observability/opentelemetry) for further details. -Then configure your Site Configuration: +Then configure your Advanced Configuration: 1. Configure `observability.tracing` > `urlTemplate` 2. Optionally, configure `observability.client`, for Sourcegraph clients to also report traces, ex. src cli -For example, if you export your traces to [Honeycomb](/self-hosted/observability/opentelemetry#otlp-compatible-backends), your Site Configuration may look like: +For example, if you export your traces to [Honeycomb](/self-hosted/observability/opentelemetry#otlp-compatible-backends), your Advanced Configuration may look like: ```json "observability.tracing": { @@ -108,7 +108,7 @@ We've also removed support for Go's net/trace format. ## Basic sampling modes -Three basic sampling modes are available in the `observability.tracing` Site Configuration: +Three basic sampling modes are available in the `observability.tracing` Advanced Configuration: ```json "observability.tracing": { diff --git a/docs/self-hosted/observability/troubleshooting.mdx b/docs/self-hosted/observability/troubleshooting.mdx index 026475302..29a05366a 100644 --- a/docs/self-hosted/observability/troubleshooting.mdx +++ b/docs/self-hosted/observability/troubleshooting.mdx @@ -13,8 +13,8 @@ issue or generating a high-quality issue report. information. Enterprise customers may alternatively file a support ticket or email `support@sourcegraph.com`. -> NOTE: This guide assumes you have site admin privileges on the Sourcegraph instance. If you are -> non-admin user, report your error the site admin and have them walk through this guide. +> NOTE: This guide assumes you have administrator privileges on the Sourcegraph instance. If you are +> non-admin user, report your error the administrator and have them walk through this guide. ## Specific scenarios @@ -82,7 +82,7 @@ find a repro if possible. If that isn't possible, file an issue with the followi 1. If you know the approximate time the issue occurred or if there is a spike in error rate around a certain time, [copy the logs](#examine-logs) around that time. 1. Note any pattern in the issue reports. E.g., did users encountering the issue all visit the same - repository or belong to the same organization. Do site admins encounter the issue or only + repository or belong to the same organization. Do administrators encounter the issue or only non-admin users? 1. [Sourcegraph configuration](#copy-configuration) 1. When was the most recent update or deployment change applied? @@ -335,7 +335,7 @@ deployment/sourcegraph-frontend --container=frontend --since=10m` ### Copy configuration Go to the URL path `/site-admin/report-bug` to obtain an all-in-one text box of all Sourcegraph -configuration (which includes site configuration, code host configuration, and global +configuration (which includes advanced configuration, code host configuration, and global settings). This lets you easily copy all configuration to an issue report (NOTE: remember to redact any secrets). diff --git a/docs/self-hosted/postgres-conf.mdx b/docs/self-hosted/postgres-conf.mdx index 1bea7cd7e..d334c15ac 100644 --- a/docs/self-hosted/postgres-conf.mdx +++ b/docs/self-hosted/postgres-conf.mdx @@ -1,8 +1,8 @@ # PostgreSQL configuration -Sourcegraph Kubernetes cluster site admins can override the default PostgreSQL configuration by supplying their own `postgresql.conf` file contents. These are specified in [`pgsql.ConfigMap.yaml`](https://github.com/sourcegraph/deploy-sourcegraph/blob/master/base/pgsql/pgsql.ConfigMap.yaml). +Sourcegraph Kubernetes cluster administrators can override the default PostgreSQL configuration by supplying their own `postgresql.conf` file contents. These are specified in [`pgsql.ConfigMap.yaml`](https://github.com/sourcegraph/deploy-sourcegraph/blob/master/base/pgsql/pgsql.ConfigMap.yaml). -For [Docker Compose](/self-hosted/deploy/docker-compose/) deployment, site admins can also override the default PostgreSQL configuration by modifying the external configuration files at [pgsql/conf/postgresql.conf], [codeintel-db/conf/postgresql.conf], and [codeinsights-db/conf/postgresql.conf]. These files are mounted to the Postgres server during runtime (NOTE: This is only available in versions 3.39 and later). +For [Docker Compose](/self-hosted/deploy/docker-compose/) deployment, administrators can also override the default PostgreSQL configuration by modifying the external configuration files at [pgsql/conf/postgresql.conf], [codeintel-db/conf/postgresql.conf], and [codeinsights-db/conf/postgresql.conf]. These files are mounted to the Postgres server during runtime (NOTE: This is only available in versions 3.39 and later). There is no officially supported way of customizing the PostgreSQL configuration in the single Docker image. diff --git a/docs/self-hosted/private-network.mdx b/docs/self-hosted/private-network.mdx index 5ad309831..bf77f6df0 100644 --- a/docs/self-hosted/private-network.mdx +++ b/docs/self-hosted/private-network.mdx @@ -100,7 +100,7 @@ This method offers several advantages: - Aligns with enterprise PKI best practices The configuration process involves identifying and adding the public key of your organization's root Certificate -Authority (CA) to Sourcegraph's site configuration. This approach is particularly efficient because: +Authority (CA) to Sourcegraph's advanced configuration. This approach is particularly efficient because: - Root CA certificates typically have long expiration periods (often measured in years) - A single root CA certificate usually covers multiple internal services @@ -158,7 +158,7 @@ MII...c= Once you've identified the root CA certificate: - Extract the certificate content including the BEGIN and END markers. -- Format the certificate for the site configuration: +- Format the certificate for the advanced configuration: - Replace newlines with \n characters - Enclose the entire certificate in double quotes - Add a trailing comma @@ -176,9 +176,11 @@ openssl s_client -showcerts -connect example.com:8443 \ | awk '{print "\"" $0 "\","}' ``` -### Add the certificate to the site configuration + -Add the formatted certificate to your Sourcegraph site configuration. +### Add the certificate to the advanced configuration + +Add the formatted certificate to your Sourcegraph advanced configuration. ```json { diff --git a/docs/self-hosted/updates/automatic.mdx b/docs/self-hosted/updates/automatic.mdx index ff45473cc..983931b4e 100644 --- a/docs/self-hosted/updates/automatic.mdx +++ b/docs/self-hosted/updates/automatic.mdx @@ -1,7 +1,7 @@ # Automatic multi-version upgrades (Deprecated) -**Deprecation Notice:** The autoupgrade feature has been removed in Sourcegraph 6.12.0 and later. Site admins should use the migrator [`upgrade` command](/self-hosted/updates/migrator/migrator-operations#upgrade) for multi-version upgrades instead. +**Deprecation Notice:** The autoupgrade feature has been removed in Sourcegraph 6.12.0 and later. Administrators should use the migrator [`upgrade` command](/self-hosted/updates/migrator/migrator-operations#upgrade) for multi-version upgrades instead. The documentation below is preserved for users on Sourcegraph versions prior to 6.12.0. @@ -15,7 +15,7 @@ The documentation below is preserved for users on Sourcegraph versions prior to From **Sourcegraph 5.1 through 6.11.x**, multi-version upgrades could be performed **automatically** as if they were a standard upgrade for the same deployment type. Automatic multi-version upgrades took the following general form: 1. Determine if your instance is ready to Upgrade: - 1. Check your Sourcegraph instances `Site admin > Updates` page. ([more info](/self-hosted/updates/#upgrade-readiness)) + 1. Check your Sourcegraph instances `Administration > Updates` page. ([more info](/self-hosted/updates/#upgrade-readiness)) 2. Consult upgrade notes for your deployment type across the range of your upgrade. ([Kubernetes](https://sourcegraph.com/changelog/self-hosted/kubernetes), [Docker-compose](https://sourcegraph.com/changelog/self-hosted/docker-compose)) 2. Merge the latest Sourcegraph release into your deployment manifests. 3. With upstream changes to your manifests merged, start the new instance. diff --git a/docs/self-hosted/updates/index.mdx b/docs/self-hosted/updates/index.mdx index bfa12e695..d560849c8 100644 --- a/docs/self-hosted/updates/index.mdx +++ b/docs/self-hosted/updates/index.mdx @@ -100,7 +100,7 @@ Sourcegraph upgrades take the following general form: ### Upgrade Readiness -Navigate to the `Site admin > Updates` page. Here you'll be notified if your instance has any **schema drift** or unfinished **out of band migrations**. +Navigate to the `Administration > Updates` page. Here you'll be notified if your instance has any **schema drift** or unfinished **out of band migrations**. ![Screenshot 2023-05-17 at 1 37 12 PM](https://storage.googleapis.com/sourcegraph-assets/docs/239155807-185fc3e8-0706-4a23-b9fe-e262f9a9e4b3.png) diff --git a/docs/self-hosted/updates/migrator/migrator-operations.mdx b/docs/self-hosted/updates/migrator/migrator-operations.mdx index 0598b482b..859b1a382 100644 --- a/docs/self-hosted/updates/migrator/migrator-operations.mdx +++ b/docs/self-hosted/updates/migrator/migrator-operations.mdx @@ -70,7 +70,7 @@ The `migrator` service exposes the following commands: ### upgrade -The `upgrade` command performs database schema migrations and out-of-band migrations to rewrite existing instance data in-place into the shaped expected by a given target Sourcegraph version. This command is used by site-administrators to perform [multi-version upgrades](/self-hosted/updates/#upgrade-types). +The `upgrade` command performs database schema migrations and out-of-band migrations to rewrite existing instance data in-place into the shaped expected by a given target Sourcegraph version. This command is used by administrators to perform [multi-version upgrades](/self-hosted/updates/#upgrade-types). ```sh upgrade \ @@ -161,7 +161,7 @@ downgrade \ ### add-log -The `add-log` command adds an entry to the `migration_logs` table after a site administrator has explicitly applied the contents of a migration definition. This command may be performed by a site-administrator as part of [repairing a dirty database](/self-hosted/how-to/dirty-database#3-add-a-migration-log-entry). +The `add-log` command adds an entry to the `migration_logs` table after an administrator has explicitly applied the contents of a migration definition. This command may be performed by an administrator as part of [repairing a dirty database](/self-hosted/how-to/dirty-database#3-add-a-migration-log-entry). ```sh add-log \ @@ -229,7 +229,7 @@ up \ ### run-out-of-band-migrations -The `run-out-of-band-migrations` command runs out-of-band migrations within the `migrator`. This command may be performed by a site-administrator as part of [repairing an unfinished migration](/self-hosted/how-to/unfinished-migration). +The `run-out-of-band-migrations` command runs out-of-band migrations within the `migrator`. This command may be performed by an administrator as part of [repairing an unfinished migration](/self-hosted/how-to/unfinished-migration). ```sh run-out-of-band-migrations \ diff --git a/docs/self-hosted/updates/migrator/troubleshooting-upgrades.mdx b/docs/self-hosted/updates/migrator/troubleshooting-upgrades.mdx index 00848b247..2f933c441 100644 --- a/docs/self-hosted/updates/migrator/troubleshooting-upgrades.mdx +++ b/docs/self-hosted/updates/migrator/troubleshooting-upgrades.mdx @@ -6,7 +6,7 @@ This document covers problems that may come up during an upgrade and ways to deb ### Reporting drift errors -If you have conducted an upgrade and see drift in your `Site admin -> Updates` page please report it to us. This is generally not a major cause of concern but may indicate problems in our `migrator` schema migration _squashing_ logic. +If you have conducted an upgrade and see drift in your `Administration -> Updates` page please report it to us. This is generally not a major cause of concern but may indicate problems in our `migrator` schema migration _squashing_ logic. Please provide us with the drift as well and if possible the contents of the `migration_logs` table in your database: diff --git a/docs/self-hosted/url.mdx b/docs/self-hosted/url.mdx index 1a5bf53f0..756f57732 100644 --- a/docs/self-hosted/url.mdx +++ b/docs/self-hosted/url.mdx @@ -2,7 +2,7 @@ It is highly recommended that you do NOT make any of the nodes running Sourcegraph directly accessible to the Internet. Instead, configure an [Internet Gateway](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Internet_Gateway.html) or equivalent to forward traffic to `httpNodePort` or `httpsNodePort` on any of the nodes in your cluster. -When that is done, update your DNS records to point to your gateway's external IP, and change the following line in your [site configuration](/admin/config/site-config): +When that is done, update your DNS records to point to your gateway's external IP, and change the following line in your [advanced configuration](/admin/config/site-config): ```json { diff --git a/docs/self-hosted/workers.mdx b/docs/self-hosted/workers.mdx index c87a6e5a6..3fc33bb72 100644 --- a/docs/self-hosted/workers.mdx +++ b/docs/self-hosted/workers.mdx @@ -82,7 +82,7 @@ This job was split from the other Code Insights background processes so that it #### `insights-data-retention-job` -This job is responsible for periodically archiving code insights data points that are beyond the maximum sample size as specified by the site config setting `insights.maximumSampleSize`. It dequeues jobs which are enqueued from the `insights-job` worker in the retention job enqueuer routine. Data will only be archived if the experimental setting `insightsDataRetention` is enabled. +This job is responsible for periodically archiving code insights data points that are beyond the maximum sample size as specified by the advanced configuration setting `insights.maximumSampleSize`. It dequeues jobs which are enqueued from the `insights-job` worker in the retention job enqueuer routine. Data will only be archived if the experimental setting `insightsDataRetention` is enabled. #### `webhook-log-janitor` diff --git a/docs/slack-integration.mdx b/docs/slack-integration.mdx index 007008fad..356a13493 100644 --- a/docs/slack-integration.mdx +++ b/docs/slack-integration.mdx @@ -113,6 +113,6 @@ All required permissions below are automatically provided via the app manifest g | `links:write` | Enables the app to post rich previews when Deep Search links are shared in Slack | | `mpim:history` | Enables the app to read message history in direct messaging groups it is added to | | `reactions:write` | Allows the app to add emoji reactions to messages, such as indicating when a Deep Search is in progress. | -| `team:read` | Allows the app to access basic information about the Slack workspace, for configuration and producing links to your Slack workspace in site admin areas. | +| `team:read` | Allows the app to access basic information about the Slack workspace, for configuration and producing links to your Slack workspace in Administration areas. | | `users:read` | Enables the app to read basic user profile information to associate Slack users with Sourcegraph accounts | | `users:read.email` | Allows the app to read user email addresses to match Slack users with their Sourcegraph accounts |