diff --git a/.github/workflows/auto-add-ready-for-doc-review.yml b/.github/workflows/auto-add-ready-for-doc-review.yml index 6315ab52bab8..a96829d134cf 100644 --- a/.github/workflows/auto-add-ready-for-doc-review.yml +++ b/.github/workflows/auto-add-ready-for-doc-review.yml @@ -34,9 +34,11 @@ jobs: github-token: ${{ secrets.DOCS_BOT_PAT_BASE }} script: | try { - await github.rest.teams.getMembershipForUserInOrg({ - org: 'github', - team_slug: 'technical-content', + // Team is addressed by numeric ID (org github = 9919, team docs = 325922) + // because IDs survive team renames and slugs do not. + await github.request('GET /organizations/{org_id}/team/{team_id}/memberships/{username}', { + org_id: 9919, + team_id: 325922, username: context.payload.sender.login, }); return true diff --git a/.github/workflows/changelog-prompt.yml b/.github/workflows/changelog-prompt.yml index bb65d8ab79d9..092d796b6f74 100644 --- a/.github/workflows/changelog-prompt.yml +++ b/.github/workflows/changelog-prompt.yml @@ -26,9 +26,11 @@ jobs: script: | try { const pr = context.payload.pull_request; - await github.rest.teams.getMembershipForUserInOrg({ - org: 'github', - team_slug: 'docs-content', + // Team is addressed by numeric ID (org github = 9919, team docs-content = 2796154) + // because IDs survive team renames and slugs do not. + await github.request('GET /organizations/{org_id}/team/{team_id}/memberships/{username}', { + org_id: 9919, + team_id: 2796154, username: pr.user.login, }); core.exportVariable('CONTINUE_WORKFLOW', 'true'); diff --git a/.github/workflows/confirm-internal-staff-work-in-docs.yml b/.github/workflows/confirm-internal-staff-work-in-docs.yml index 8f6e8270ad98..f655b4655ba9 100644 --- a/.github/workflows/confirm-internal-staff-work-in-docs.yml +++ b/.github/workflows/confirm-internal-staff-work-in-docs.yml @@ -46,9 +46,11 @@ jobs: // Don't perform this action with Docs team members try { - await github.rest.teams.getMembershipForUserInOrg({ - org: 'github', - team_slug: 'technical-content', + // Team is addressed by numeric ID (org github = 9919, team docs = 325922) + // because IDs survive team renames and slugs do not. + await github.request('GET /organizations/{org_id}/team/{team_id}/memberships/{username}', { + org_id: 9919, + team_id: 325922, username: context.payload.sender.login, }); // If the user is a Docs team member, we should stop here and not send diff --git a/.github/workflows/copy-api-issue-to-internal.yml b/.github/workflows/copy-api-issue-to-internal.yml index 58fa499ebc97..1c24f6dbc800 100644 --- a/.github/workflows/copy-api-issue-to-internal.yml +++ b/.github/workflows/copy-api-issue-to-internal.yml @@ -26,8 +26,10 @@ jobs: result-encoding: string script: | const triggerer_login = context.payload.sender.login + // Team is addressed by numeric ID (org github = 9919, team docs = 325922) + // because IDs survive team renames and slugs do not. const teamMembers = await github.request( - `/orgs/github/teams/technical-content/members?per_page=100` + `/organizations/9919/team/325922/members?per_page=100` ) const logins = teamMembers.data.map(member => member.login) if (logins.includes(triggerer_login)) { diff --git a/.github/workflows/feedback-prompt.yml b/.github/workflows/feedback-prompt.yml index 4da61e32065a..dace8f90a87f 100644 --- a/.github/workflows/feedback-prompt.yml +++ b/.github/workflows/feedback-prompt.yml @@ -26,9 +26,11 @@ jobs: script: | try { const pr = context.payload.pull_request; - await github.rest.teams.getMembershipForUserInOrg({ - org: 'github', - team_slug: 'docs-content', + // Team is addressed by numeric ID (org github = 9919, team docs-content = 2796154) + // because IDs survive team renames and slugs do not. + await github.request('GET /organizations/{org_id}/team/{team_id}/memberships/{username}', { + org_id: 9919, + team_id: 2796154, username: pr.user.login, }); // Author is in the team. Do nothing! diff --git a/.github/workflows/hubber-contribution-help.yml b/.github/workflows/hubber-contribution-help.yml index e8823ffa7e20..45eec0641fde 100644 --- a/.github/workflows/hubber-contribution-help.yml +++ b/.github/workflows/hubber-contribution-help.yml @@ -31,9 +31,11 @@ jobs: github-token: ${{ secrets.DOCS_BOT_PAT_BASE }} script: | try { - await github.rest.teams.getMembershipForUserInOrg({ - org: 'github', - team_slug: 'technical-content', + // Team is addressed by numeric ID (org github = 9919, team docs = 325922) + // because IDs survive team renames and slugs do not. + await github.request('GET /organizations/{org_id}/team/{team_id}/memberships/{username}', { + org_id: 9919, + team_id: 325922, username: context.payload.sender.login, }); return true diff --git a/.github/workflows/os-ready-for-review.yml b/.github/workflows/os-ready-for-review.yml index c9429ddfbf8b..3c3cd37aff82 100644 --- a/.github/workflows/os-ready-for-review.yml +++ b/.github/workflows/os-ready-for-review.yml @@ -30,8 +30,10 @@ jobs: result-encoding: string script: | const triggerer_login = context.payload.sender.login + // Team is addressed by numeric ID (org github = 9919, team docs = 325922) + // because IDs survive team renames and slugs do not. const teamMembers = await github.request( - `/orgs/github/teams/technical-content/members?per_page=100` + `/organizations/9919/team/325922/members?per_page=100` ) const logins = teamMembers.data.map(member => member.login) if (logins.includes(triggerer_login)) { diff --git a/content/admin/data-residency/github-copilot-with-data-residency.md b/content/admin/data-residency/github-copilot-with-data-residency.md index da3377ab56ec..00c92259de1e 100644 --- a/content/admin/data-residency/github-copilot-with-data-residency.md +++ b/content/admin/data-residency/github-copilot-with-data-residency.md @@ -61,6 +61,9 @@ The models available for {% data variables.product.prodname_copilot_short %} var * {% data variables.copilot.copilot_gpt_54_mini %} * {% data variables.copilot.copilot_gpt_54_nano %} * {% data variables.copilot.copilot_gpt_55 %} +* {% data variables.copilot.copilot_gpt_56_luna %} +* {% data variables.copilot.copilot_gpt_56_sol %} +* {% data variables.copilot.copilot_gpt_56_terra %} * {% data variables.copilot.copilot_claude_haiku_45 %} * {% data variables.copilot.copilot_claude_opus_45 %} * {% data variables.copilot.copilot_claude_opus_46 %} diff --git a/content/copilot/concepts/about-cloud-and-local-sandboxes.md b/content/copilot/concepts/about-cloud-and-local-sandboxes.md index 20c8a65cd016..8d57f2b5ccd8 100644 --- a/content/copilot/concepts/about-cloud-and-local-sandboxes.md +++ b/content/copilot/concepts/about-cloud-and-local-sandboxes.md @@ -43,6 +43,8 @@ Local sandboxing is powered by Microsoft eXecution Container (MXC), a cross-plat Isolation technologies exist on a spectrum, from strong isolation such as full hypervisors or containers, to lighter-weight isolation such as OS-level process and filesystem containment. Local sandboxing currently sits at the lighter-weight end of this spectrum: it restricts what a process can read, write, and reach on the network, but it does not run your commands inside a separate virtual machine or container. If you want to evaluate whether this level of isolation meets your security requirements, see the [microsoft/mxc repository](https://github.com/microsoft/mxc) for implementation details. +For more information, see [AUTOTITLE](/copilot/concepts/agents/copilot-cli/understanding-local-sandboxing). + ### Enabling local sandboxing To enable local sandboxing inside a {% data variables.copilot.copilot_cli_short %} session, run: diff --git a/content/copilot/concepts/agents/copilot-cli/index.md b/content/copilot/concepts/agents/copilot-cli/index.md index 28da0d19082d..cff6e182d98e 100644 --- a/content/copilot/concepts/agents/copilot-cli/index.md +++ b/content/copilot/concepts/agents/copilot-cli/index.md @@ -21,6 +21,7 @@ children: - /lsp-servers - /about-cli-extensions - /tool-search + - /understanding-local-sandboxing contentType: concepts docsTeamMetrics: - copilot-cli diff --git a/content/copilot/concepts/agents/copilot-cli/understanding-local-sandboxing.md b/content/copilot/concepts/agents/copilot-cli/understanding-local-sandboxing.md new file mode 100644 index 000000000000..12f5b36d2a49 --- /dev/null +++ b/content/copilot/concepts/agents/copilot-cli/understanding-local-sandboxing.md @@ -0,0 +1,122 @@ +--- +title: Understanding filesystem policies for local sandboxing in {% data variables.copilot.copilot_cli %} +shortTitle: Understanding local sandboxing +allowTitleToDifferFromFilename: true +intro: 'When local sandboxing is enabled, {% data variables.copilot.copilot_cli_short %} runs each sandboxed process or operation under a filesystem policy that controls which files and directories it can read and write. Learn how that policy is built and how to check the access it grants.' +versions: + feature: copilot +contentType: concepts +category: + - Learn about Copilot + - Learn about Copilot CLI +docsTeamMetrics: + - copilot-cli +--- + +{% data reusables.cli.public-preview-local-sandbox %} + +{% data reusables.cli.sandbox-on-windows %} + +## Introduction + +When you enable local sandboxing, {% data variables.copilot.copilot_cli_short %} runs the commands it invokes on your behalf inside an operating-system sandbox. The sandbox enforces a **filesystem policy**: a set of rules that decide which paths a sandboxed process or operation can read, which it can write, and which it cannot touch at all. + +Most of this policy is assembled automatically, so that everyday commands keep working without setup. This article explains how {% data variables.product.prodname_copilot_short %} arrives at the policy, and how to check the access it grants in a particular directory. + +For an overview of local sandboxing, including how to turn it on and off, see [AUTOTITLE](/copilot/concepts/about-cloud-and-local-sandboxes) and [AUTOTITLE](/copilot/how-tos/cloud-and-local-sandboxes/using-local-sandboxing). + +## What the policy applies to + +The filesystem policy covers the work {% data variables.product.prodname_copilot_short %} does on your behalf, but it is enforced in different ways depending on the kind of work: + +* **Shell commands and built-in searches** run as sandboxed child processes, so the operating system enforces the policy directly. The `grep` and `glob` tools, for example, run ripgrep as a sandboxed child process. +* **Local MCP and language server processes (LSP)** can also run inside the sandbox, so the operating system enforces the policy on them too. +* **Built-in file-reading and file-editing tools** run as part of {% data variables.copilot.copilot_cli_short %} itself rather than as a sandboxed child process. They check the same filesystem policy before reading or writing a file, but because the operating-system sandbox never sees these operations, the check is a software-only safeguard rather than one the operating system enforces. +* **Remote MCP servers** run outside your machine, so there is no local child process to sandbox and the filesystem policy does not constrain them. +* **Subagents** do not act directly; they orchestrate other tools. Whether the policy applies, and how, depends on the tool a subagent invokes. + +A sandboxed **process** is therefore constrained by the operating system, while an in-process **operation** enforces the same policy in software—which is why this article refers to a sandboxed process or operation rather than only to commands. + +## Permission levels + +The sandbox is **deny-by-default**: unless a path is explicitly granted, a command cannot use it. Every path in the policy has one of three permission levels: + +* **Read/write** — the command can read and modify files at this path. +* **Read-only** — the command can read files at this path, but not change them. +* **Denied** — the command cannot read or write at this path, even if a broader rule would otherwise allow it. + +Because access is denied unless granted, {% data variables.product.prodname_copilot_short %} must grant a command everything it legitimately needs—your project files, the tools it runs, and supporting locations such as temporary directories—while keeping everything else off-limits. + +> [!NOTE] +> These permission levels apply to every sandboxed process or operation, but they are enforced differently: for sandboxed child processes the operating system enforces them directly, while the CLI's own built-in file-reading and file-editing tools check the same levels in software, without an operating-system backstop. + +## How the policy is built + +Before each sandboxed process starts, {% data variables.copilot.copilot_cli_short %} resolves the effective policy for that process using the current working directory, environment, settings, and automatic grants. This restricts the process to only the access that it needs, and means you don't have to manage these common locations yourself. + +### Your working directory + +When **Include working directory** is enabled in the filesystem settings for local sandboxing—as it is by default—the current working directory is granted read/write access. In a Git repository, {% data variables.product.prodname_copilot_short %} also adds the associated Git grants. Turning this setting off suppresses all of those automatic grants so you must add allow rules for the required project and Git paths manually. See [AUTOTITLE](/copilot/how-tos/cloud-and-local-sandboxes/configuring-local-sandbox-settings). + +> [!NOTE] +> If you get {% data variables.product.prodname_copilot_short %} from an enterprise-owned organization, an administrator can turn off the **Include working directory** setting and lock it, so you can't turn it back on. See [AUTOTITLE](/copilot/reference/enterprise-administrators/enterprise-managed-settings#sandbox). + +### Tools on your PATH + +To run a program such as `python` or `git`, the sandbox has to let the command see the directory the program lives in. Your `PATH` environment variable lists these directories, and {% data variables.product.prodname_copilot_short %} grants them **read-only** access, along with directories named by related tool variables such as `GOPATH`, `CARGO_HOME`, and `PYTHONPATH`. Read-only is the right level for external tools: a command needs to run `git`, not modify it. For the complete list of the `PATH` and toolchain environment variables the sandbox inspects, and how each one is interpreted, see [AUTOTITLE](/copilot/reference/copilot-cli-reference/cli-command-reference#sandbox-tool-directory-grants). + +### System and profile locations + +Standard system locations and your user profile (home) directory are granted read-only, so that commands can read configuration files and shared libraries without being able to change them. + +### Package-manager caches + +To let installs and builds work inside the sandbox, {% data variables.product.prodname_copilot_short %} also grants access to the caches and registries used by common package managers and toolchains—read-only for registries and toolchains, and read/write for build caches. In the `/sandbox policy` report, this appears as **dev-tool access**. + +### Git repositories + +When you work in a subdirectory of a Git repository, {% data variables.product.prodname_copilot_short %} grants **read** access to the whole repository so that commands can see the full project, while limiting **writes** to your current working directory and the repository's Git metadata (its `.git` directory). This lets a command read across the repository but keeps changes focused on where you are working. + +Because read access spans the whole repository, a sandboxed command can read files outside your current subdirectory, including anything sensitive stored elsewhere in the project. To keep specific paths out of reach, you can add deny rules. See [AUTOTITLE](/copilot/how-tos/cloud-and-local-sandboxes/configuring-local-sandbox-settings). + +## When access rules overlap + +Because {% data variables.product.prodname_copilot_short %} grants several locations, and you can add your own, the rules can overlap. When they do, the **more specific path wins**. For example, if `/project` is writable but you mark `/project/secrets` read-only, everything in `/project` stays writable except `/project/secrets`. This is a useful way to protect a sensitive subfolder. + +Overlaps are also resolved in your favor when a convenience grant would otherwise get in the way. Consider a Python project with a local virtual environment (`.venv`) that appears on your `PATH`. Treating that directory as an ordinary read-only tool location would make it read-only—even though it sits inside your writable project—and a command such as `pip install` could then fail when it tried to update the environment. {% data variables.product.prodname_copilot_short %} resolves this for you: a grant it added automatically (such as a tool directory on `PATH`) gives way to a broader read/write grant that already covers it. So a project-local `.venv`, `node_modules/.bin`, or similar directory stays writable as part of your workspace. + +Rules that **you** configure are always kept. If you mark a path read-only, or you deny it, that decision stands even when the same path would otherwise be discovered and granted automatically. This gives you a reliable way to protect a sensitive location—for example, denying a `.env` file so that no sandboxed command can read your secrets. + +## Checking what the current policy allows + +Because the policy is assembled for each directory and command, the simplest way to see the access you have is to ask {% data variables.copilot.copilot_cli_short %}. In a session, enter: + +```shell copy +/sandbox policy +``` + +{% data variables.product.prodname_copilot_short %} prints the **effective** policy for your current directory: the read/write, read-only, and denied paths that a command launched from here would actually receive, together with the network access and dev-tool access in force. This is the resolved result after the automatic grants and your own settings have been combined and any overlaps resolved—not just a copy of your saved settings. + +A few things to keep in mind when you read the report: + +* It reflects your **current directory**. Because grants are discovered per directory, the same settings can resolve to different paths depending on where you run. +* If a path you configured does not exist on disk, it is left out of the policy and noted in a **Notes** section. This explains why a rule you added might appear to have no effect. +* If sandboxing is turned off, `/sandbox policy` tells you so instead of printing a policy, because no restrictions are in force. + +To check only whether sandboxing is currently on, use `/sandbox status`. For more about these commands, see [AUTOTITLE](/copilot/how-tos/cloud-and-local-sandboxes/using-local-sandboxing). + +## Customizing the policy + +You can grant extra read/write or read-only paths, deny paths, and change other filesystem behavior, either from the `/sandbox config` dialog or in your settings file. After you make a change, run `/sandbox policy` to confirm the result. For step-by-step instructions, see [AUTOTITLE](/copilot/how-tos/cloud-and-local-sandboxes/configuring-local-sandbox-settings). + +## Enterprise-managed policies + +If you get {% data variables.product.prodname_copilot_short %} through an enterprise-owned organization, an administrator can enforce a filesystem policy through managed settings. Managed settings act as a baseline that you cannot loosen: they can require sandboxing, add denied paths, and limit which paths you are allowed to grant. Where a managed setting applies, the `/sandbox config` dialog shows it as a locked **(managed)** value, and `/sandbox policy` reflects it in the resolved policy. + +Unlike most settings, where a single source wins, the sandbox policy is composed from every source in force at once. Managed settings can arrive through more than one channel simultaneously—server-managed, MDM, and file-based—and these combine with each other, and with your own settings, in the **most restrictive** direction rather than one source overriding another: a required toggle stays on, denied paths from all sources add up, and the paths you are allowed to grant can only be narrowed. For more information, see [AUTOTITLE](/copilot/reference/enterprise-administrators/enterprise-managed-settings#sandbox). + +## Further reading + +* [AUTOTITLE](/copilot/concepts/about-cloud-and-local-sandboxes) +* [AUTOTITLE](/copilot/how-tos/cloud-and-local-sandboxes/using-local-sandboxing) +* [AUTOTITLE](/copilot/how-tos/cloud-and-local-sandboxes/configuring-local-sandbox-settings) diff --git a/content/copilot/concepts/copilot-usage-metrics/copilot-metrics.md b/content/copilot/concepts/copilot-usage-metrics/copilot-metrics.md index e53444b0f787..352cba7a4ad0 100644 --- a/content/copilot/concepts/copilot-usage-metrics/copilot-metrics.md +++ b/content/copilot/concepts/copilot-usage-metrics/copilot-metrics.md @@ -166,13 +166,3 @@ These metrics can be used together to answer key questions about your teams' usa | How do I act on the insights from the dashboard? | See [AUTOTITLE](/copilot/reference/copilot-usage-metrics/interpret-copilot-metrics#reviewing-adoption-cohorts) | Look for patterns across these signals rather than focusing on any single number. For example, a steady DAU paired with a rising acceptance rate indicates growing trust and value. - -## Next steps - -Now that you understand what each {% data variables.product.prodname_copilot_short %} metric measures and how to use them, you can explore the dashboards to see these metrics in action. - -* To view adoption and usage trends across your enterprise and organizations, see [AUTOTITLE](/copilot/how-tos/administer-copilot/view-usage-and-adoption). -* To analyze how code is being generated by users and agents, see [AUTOTITLE](/copilot/how-tos/administer-copilot/view-code-generation). -* To view adoption cohorts and depth of adoption, see [AUTOTITLE](/copilot/how-tos/administer-copilot/view-impact-dashboard). -* To access {% data variables.product.prodname_copilot_short %} usage metrics programmatically, see [AUTOTITLE](/rest/copilot/copilot-usage-metrics). -* To construct team-level metrics by aggregating per-user records, see [AUTOTITLE](/copilot/reference/copilot-usage-metrics/team-level-metrics). diff --git a/content/copilot/concepts/index.md b/content/copilot/concepts/index.md index 0a02b2d313f1..7d1eb5dcd5dd 100644 --- a/content/copilot/concepts/index.md +++ b/content/copilot/concepts/index.md @@ -24,4 +24,3 @@ children: - /learning-about-new-features-and-models contentType: concepts --- - diff --git a/content/copilot/how-tos/administer-copilot/view-code-generation.md b/content/copilot/how-tos/administer-copilot/view-code-generation.md index 09e727029d42..c686991ab804 100644 --- a/content/copilot/how-tos/administer-copilot/view-code-generation.md +++ b/content/copilot/how-tos/administer-copilot/view-code-generation.md @@ -34,7 +34,3 @@ For a detailed list of available metrics and definitions, see [AUTOTITLE](/copil {% data reusables.copilot.access-copilot-metrics-dashboard %} 1. In the left sidebar, click **Code generation**. - -## Next steps - -To learn how to interpret the data in each chart and act on usage trends, see [AUTOTITLE](/copilot/reference/copilot-usage-metrics/interpret-copilot-metrics). diff --git a/content/copilot/how-tos/administer-copilot/view-impact-dashboard.md b/content/copilot/how-tos/administer-copilot/view-impact-dashboard.md index 45780ddcc822..e49c155e421f 100644 --- a/content/copilot/how-tos/administer-copilot/view-impact-dashboard.md +++ b/content/copilot/how-tos/administer-copilot/view-impact-dashboard.md @@ -25,8 +25,3 @@ For a detailed explanation of what the dashboard shows, including adoption cohor {% data reusables.copilot.access-copilot-metrics-dashboard %} 1. In the left sidebar, click **{% data variables.product.prodname_copilot_short %} impact**. - -## Next steps - -* To learn how to interpret cohort shifts and what action to take, see [AUTOTITLE](/copilot/reference/copilot-usage-metrics/interpret-copilot-metrics#reviewing-adoption-cohorts). -* For raw per-team NDJSON data, such as for custom BI reporting, see [AUTOTITLE](/copilot/reference/copilot-usage-metrics/team-level-metrics). diff --git a/content/copilot/how-tos/administer-copilot/view-usage-and-adoption.md b/content/copilot/how-tos/administer-copilot/view-usage-and-adoption.md index 3e548c4d2d0f..d55ae1337e05 100644 --- a/content/copilot/how-tos/administer-copilot/view-usage-and-adoption.md +++ b/content/copilot/how-tos/administer-copilot/view-usage-and-adoption.md @@ -36,9 +36,3 @@ For deeper analysis, you can export NDJSON reports from the dashboard and use {% * Which users have `user_initiated_interaction_count` > 0 but low `code_acceptance_activity_count`? * Are there specific teams with lower adoption rates? ``` - -## Next steps - -* To learn how to interpret the data in each chart and act on usage trends, see [AUTOTITLE](/copilot/reference/copilot-usage-metrics/interpret-copilot-metrics). -* To learn how to track license activation and initial usage of {% data variables.product.prodname_copilot %} with usage metrics, see [AUTOTITLE](/copilot/tutorials/roll-out-at-scale/assign-licenses/track-usage-and-adoption). -* To access usage data programmatically, see [AUTOTITLE](/rest/copilot/copilot-usage-metrics). diff --git a/content/copilot/how-tos/cloud-and-local-sandboxes/configuring-local-sandbox-settings.md b/content/copilot/how-tos/cloud-and-local-sandboxes/configuring-local-sandbox-settings.md index c6bf1b0cd7d2..b64c12fef1c5 100644 --- a/content/copilot/how-tos/cloud-and-local-sandboxes/configuring-local-sandbox-settings.md +++ b/content/copilot/how-tos/cloud-and-local-sandboxes/configuring-local-sandbox-settings.md @@ -27,7 +27,7 @@ For a conceptual overview of cloud and local sandboxes for {% data variables.pro 1. Start a {% data variables.copilot.copilot_cli_short %} session. 1. Enter the `/sandbox` slash command. - This opens an interactive configuration interface with three tabs: **General**, **Filesystem**, and **Network**. Use Tab to switch between tabs. Press Esc to save your changes and close the configuration. + This opens an interactive configuration interface with four tabs: **General**, **Auth**, **Filesystem**, and **Network**. Use Tab to switch between tabs. Press Esc to save your changes and close the configuration. ## Configuring general settings @@ -39,9 +39,6 @@ The **General** tab controls the top-level sandbox behavior. When enterprise man | **Allow sandbox bypass** | Let the model request that individual commands run outside the sandbox, subject to approval. Turned on by default. For more information, see [Allowing sandbox bypass](#allowing-sandbox-bypass). | | **Sandbox MCP servers** | Run MCP servers inside the sandbox. Turned on by default. | | **Sandbox LSP servers** | Run language servers (LSP servers) inside the sandbox. Turned on by default. | -| **Authenticate git** | Inject a {% data variables.product.github %} token so authenticated HTTPS `git` works inside the sandbox without a credential helper. Turned on by default. | -| **Authenticate gh** | Export `GH_TOKEN` so that {% data variables.product.prodname_cli %} (note: the `gh` CLI, not `copilot`) works inside the sandbox without reaching its stored credentials (configuration directory or OS keychain), which the sandbox blocks. Turned on by default. | -| **Allow keychain access** | Available on macOS only. Let sandboxed commands use the macOS Keychain—for example, to access credentials used by `git` and `gh` credential helpers. Turned off by default. | ### Allowing sandbox bypass @@ -50,6 +47,16 @@ The **Allow sandbox bypass** setting controls what happens when {% data variable * **On (default)**: If a command fails inside the sandbox, you are prompted to allow {% data variables.product.prodname_copilot_short %} to run the command outside the sandbox. Your response to this prompt applies to this specific attempt to run the command. Optionally, you can choose to disable the sandbox for the rest of the session (if permitted by your enterprise), or you can enter an instruction for {% data variables.product.prodname_copilot_short %} to work on instead. * **Off**: If {% data variables.product.prodname_copilot_short %} can't run a command successfully in the sandbox, it stops working on the task and reports the failure. +## Configuring authentication settings + +The **Auth** tab controls whether your credentials are made available to commands running inside the sandbox. As on the other tabs, an enterprise-managed value is shown as `(managed)` and can't be changed. + +| Setting | Description | +| --- | --- | +| **Authenticate git** | Inject a {% data variables.product.github %} token so authenticated HTTPS `git` works inside the sandbox without a credential helper. For non-GitHub hosts, your own stored credentials are made available to sandboxed `git` commands instead. Turned on by default. | +| **Authenticate gh** | Export `GH_TOKEN` so that {% data variables.product.prodname_cli %} (note: the `gh` CLI, not `copilot`) works inside the sandbox without reaching its stored credentials (configuration directory or OS keychain), which the sandbox blocks. Turned on by default. | +| **Allow keychain access** | Available on macOS only. Let sandboxed commands use the macOS Keychain—for example, to access credentials used by `git` and `gh` credential helpers. Turned off by default. | + ## Configuring filesystem settings The **Filesystem** tab controls which directories and files the sandboxed process can access. @@ -57,12 +64,12 @@ The **Filesystem** tab controls which directories and files the sandboxed proces By default, {% data variables.product.prodname_copilot_short %} is granted read/write permission to everything in and below the current working directory. If you are in a Git repository, {% data variables.product.prodname_copilot_short %} is also granted: * Read/write permission to everything in and below the repository's `.git` directory. -* On Windows and macOS, read permission for everything else in the repository above the current working directory. -* On Linux, read/write permission for files above the current working directory in the repository. +* Read permission for everything else in the repository above the current working directory. The working directory itself stays read/write, because the more specific grant wins where the two overlap. | Setting | Description | | --- | --- | | **Include working directory** | Turned on by default. The current working directory (and the enclosing repository's `.git` directory, if any) is automatically added to the list of read/write paths. Unselect this option if you don't want the working directory to be granted read/write access automatically, and then manually allow access to specific paths. | +| **Allow dev tool access** | Turned on by default. Grants sandboxed commands read access to developer-tool configuration and caches—including package-manager registries and the tokens they store—and read/write access to shared build caches, so installs and builds work inside the sandbox. This appears as **dev-tool access** in the `/sandbox policy` report. Turn it off to require these locations to be granted explicitly. | > [!IMPORTANT] > Unselecting **Include working directory** removes access to everything in and below the `.git` directory of a Git repository. As a result, Git operations such as `status`, `add`, `commit`, and `diff` will fail unless you manually add access for this directory. @@ -75,7 +82,7 @@ You can specify paths that you want to add to the sandbox. This allows you to gr 1. Type a file or directory path. Use an absolute path—for example, `/Users/octocat/projects/app` on macOS or Linux, or `C:\Users\octocat\projects\app` on Windows. Then press Enter. > [!NOTE] - > Adding a directory includes it entire subtree. Wildcards are not supported. + > Adding a directory includes its entire subtree. Wildcards are not supported. 1. Use the left and right arrow keys on your keyboard to navigate between the permissions options: **Read/Write**, **Read-Only**, **Denied**. Then press Enter to select an option. @@ -92,6 +99,18 @@ The **Network** tab controls whether sandboxed processes can make network connec | --- | --- | | **Allow outbound connections** | Turned on by default. When turned on, the sandboxed process can reach external hosts on the internet. Turn this off to fully isolate the sandbox from the network. | | **Allow local network** | Turned on by default. When turned on, the sandboxed process can reach hosts on your local network (for example, `localhost` or other devices on your LAN). Turn this off to block the sandbox from reaching local or private network services. | +| **HTTP Proxy** | Route the sandbox's outbound traffic through an HTTP proxy. See [Routing traffic through an HTTP proxy](#routing-traffic-through-an-http-proxy). | + +### Routing traffic through an HTTP proxy + +Select **HTTP Proxy** on the **Network** tab to send the sandbox's outbound traffic through a proxy server. Enter the proxy **URL**, and optionally a **Username** and **Password**. To remove the proxy, clear the URL. + +Keep the following in mind: + +* The proxy applies only while **Allow outbound connections** is turned on. If you turn outbound connections off, the proxy is kept in your settings but stays inactive. +* The password is stored securely in your operating system's credential store. You can also enter a `${VAR}` environment-variable reference instead of a literal password. +* On Linux and macOS, the proxy is cooperative: it is applied through standard proxy environment variables and depends on each tool honoring them. On Windows, the sandbox enforces the proxy. +* Your organization can enforce the proxy URL through managed settings. When it does, the URL is shown as `(managed)`, but you can still provide your own credentials, which are stored in your user settings. ## Enabling and disabling the sandbox quickly @@ -112,6 +131,8 @@ You can view your current sandbox settings from within a {% data variables.copil 1. Press / to search for settings. 1. Type `sandbox` to filter the list of settings. +The steps above show your saved settings. To see the **effective** filesystem policy—the read/write, read-only, and denied paths that result once your settings, the automatic grants, and any managed policy are combined—enter `/sandbox policy`. For more information, see [AUTOTITLE](/copilot/concepts/agents/copilot-cli/understanding-local-sandboxing). + ## Further reading * [AUTOTITLE](/copilot/concepts/about-cloud-and-local-sandboxes) diff --git a/content/copilot/how-tos/cloud-and-local-sandboxes/using-local-sandboxing.md b/content/copilot/how-tos/cloud-and-local-sandboxes/using-local-sandboxing.md index 791f0d1f9c32..8e90ca24c3e6 100644 --- a/content/copilot/how-tos/cloud-and-local-sandboxes/using-local-sandboxing.md +++ b/content/copilot/how-tos/cloud-and-local-sandboxes/using-local-sandboxing.md @@ -22,12 +22,24 @@ Sandboxing is currently an experimental feature. To use it, start {% data variab When you enable local sandboxing, {% data variables.copilot.copilot_cli_short %} runs most of the commands and tools it invokes on your behalf inside an operating-system sandbox. After you enable local sandboxing, it is used for all your {% data variables.copilot.copilot_cli_short %} sessions until you disable it, or turn it off for a specific session. If enterprise managed settings require sandboxing, you cannot disable it. -By default, sandboxed commands and tools can write within your current working directory and temporary folders. Your user profile (home) directory, along with system and tool locations are read-only. Other disk locations are blocked. In a Git repository, access above the current working directory varies by operating system. Access to your local and private network is permitted, as is outbound internet access. +By default, sandboxed commands and tools can write within your current working directory and temporary folders. Your user profile (home) directory, along with system and tool locations are read-only. Other disk locations are blocked. In a Git repository, the rest of the repository above your current working directory is readable but not writable. Access to your local and private network is permitted, as is outbound internet access. By default, authenticated Git and {% data variables.product.prodname_cli %} (`gh`) operations continue to work inside the sandbox, because {% data variables.copilot.copilot_cli_short %} makes your {% data variables.product.github %} credentials available to sandboxed commands. This allows actions such as `git push` and `gh pr create` to succeed. You can turn this off in your sandbox settings. For a conceptual overview of sandboxing in {% data variables.copilot.copilot_cli_short %}, see [AUTOTITLE](/copilot/concepts/about-cloud-and-local-sandboxes). +## Sandbox commands + +You manage local sandboxing from within a {% data variables.copilot.copilot_cli_short %} session using the `/sandbox` slash command. It has the following subcommands. + +| Command | Description | +| --- | --- | +| `/sandbox status` | Show whether sandboxing is currently being used for the session. See [Checking whether sandboxing is being used](#checking-whether-sandboxing-is-being-used). | +| `/sandbox policy` | Show the effective filesystem policy for the current directory—the paths that are readable, writable, or blocked, and the network access in force. For more information, see [AUTOTITLE](/copilot/concepts/agents/copilot-cli/understanding-local-sandboxing). | +| `/sandbox config` | Open the interactive settings interface. Entering `/sandbox` on its own does the same thing. For more information, see [AUTOTITLE](/copilot/how-tos/cloud-and-local-sandboxes/configuring-local-sandbox-settings). | +| `/sandbox enable` | Turn local sandboxing on. See [Enabling local sandboxing](#enabling-local-sandboxing). | +| `/sandbox disable` | Turn local sandboxing off. If enterprise managed settings require sandboxing, this is refused. See [Disabling local sandboxing](#disabling-local-sandboxing). | + ## Enabling local sandboxing To enable local sandboxing, enter the following command in an interactive {% data variables.copilot.copilot_cli_short %} session: @@ -78,9 +90,17 @@ This behavior is enabled by default and can be turned off in your sandbox settin ## Checking whether sandboxing is being used -To check whether sandboxing is being used for the current session, look at the status line. If sandboxing is being used, the status line contains `sandbox enabled`. +To check whether local sandboxing is being used for the current session, enter: + +```shell copy +/sandbox status +``` + +{% data variables.copilot.copilot_cli_short %} reports whether sandboxing is enabled for the session. If your organization's managed settings require sandboxing, the status notes this too. Because the status reflects what the session actually enforces, it is the reliable way to confirm whether the commands {% data variables.product.prodname_copilot_short %} runs are being sandboxed. + +To see not only whether sandboxing is on, but exactly which paths are readable, writable, or blocked, enter `/sandbox policy`. For more information, see [AUTOTITLE](/copilot/concepts/agents/copilot-cli/understanding-local-sandboxing). -Display of sandbox information in the status line is turned on by default. If it is turned off, you can turn it back on: +You can also see sandbox status at a glance in the status line, which contains `sandbox enabled` when sandboxing is being used. Display of sandbox information in the status line is turned on by default. If it has been turned off, you can turn it back on: 1. Enter `/statusline`. 1. Move the selection down the list of options to **sandbox**. diff --git a/content/copilot/reference/copilot-allowlist-reference.md b/content/copilot/reference/copilot-allowlist-reference.md index 8b5bbe79cbb9..d39fea8cdb5f 100644 --- a/content/copilot/reference/copilot-allowlist-reference.md +++ b/content/copilot/reference/copilot-allowlist-reference.md @@ -22,7 +22,7 @@ Every user of the proxy server or firewall also needs to configure their own env We recommend using the `/meta` API endpoint to find the domains required to use {% data variables.product.github %} on a restricted network. For more information, see [AUTOTITLE](/get-started/using-github/allowing-access-to-githubs-services-from-a-restricted-network). -The following request returns most of the wildcard domains required to authenticate and connect to {% data variables.product.prodname_copilot_short %} on {% data variables.product.prodname_dotcom_the_website %}. There are some exceptions for specific services, or if you want to allow traffic based only for specific {% data variables.product.prodname_copilot_short %} plans. +The following request returns most of the wildcard domains required to authenticate and connect to {% data variables.product.prodname_copilot_short %} on {% data variables.product.prodname_dotcom_the_website %}. There are some exceptions for specific services, or if you want to allow traffic only for users with specific {% data variables.product.prodname_copilot_short %} plans. ```shell copy gh api meta -q '.domains | .website, .copilot' @@ -77,7 +77,7 @@ All other domains that are required on {% data variables.product.prodname_dotcom ## Editor-specific requirements -In addition to the URLs required to connect to {% data variables.product.prodname_copilot_short %}, you must ensure your network rules meet the requirements the local client (for example, outbound requests to `vscode.dev` in {% data variables.product.prodname_vscode %}). Find the documentation for your chosen client, for example: +In addition to the URLs required to connect to {% data variables.product.prodname_copilot_short %}, you must ensure your network rules meet the requirements of the local client (for example, outbound requests to `vscode.dev` in {% data variables.product.prodname_vscode %}). Find the documentation for your chosen client, for example: * [Network Connections in {% data variables.product.prodname_vscode %}](https://code.visualstudio.com/docs/setup/network) in the {% data variables.product.prodname_vs %} documentation * [Install and use {% data variables.product.prodname_vs %} and Azure Services behind a firewall or proxy server](https://learn.microsoft.com/en-us/visualstudio/install/install-and-use-visual-studio-behind-a-firewall-or-proxy-server) in the Microsoft documentation diff --git a/content/copilot/reference/copilot-cli-reference/cli-command-reference.md b/content/copilot/reference/copilot-cli-reference/cli-command-reference.md index 0172250ca7b5..552a1f3bd599 100644 --- a/content/copilot/reference/copilot-cli-reference/cli-command-reference.md +++ b/content/copilot/reference/copilot-cli-reference/cli-command-reference.md @@ -1221,6 +1221,42 @@ To allow `web_fetch` to reach `localhost` during development—for example, for export COPILOT_WEB_FETCH_ALLOW_LOCALHOST=1 ``` +### Sandbox tool directory grants + +When local sandboxing is enabled, {% data variables.copilot.copilot_cli_short %} discovers the tool directories a sandboxed command is likely to need and grants each one **read-only** access, so a command can run an installed toolchain without being able to modify it. Discovery runs for each command, before the process starts, and reads two kinds of source from the command's environment. + +* **`PATH`** (`Path` on Windows). Every directory listed is a candidate grant. +* **Named toolchain variables.** The CLI inspects the variables in the table below on every operating system. A variable that holds a single directory grants that directory; a variable that holds a path list is split on the operating system's path separator (`;` on Windows, `:` elsewhere), and each entry becomes a candidate grant. + +A candidate is granted only when it is an absolute path that exists and resolves to a directory. Candidates are dropped—and the reason logged to the `sandbox_spawn` log target—when they are relative, do not exist, resolve to a filesystem root (such as `/` or `C:\`), or resolve under a system-critical location (`%WINDIR%` on Windows; `/bin`, `/sbin`, `/usr/bin`, `/usr/sbin`, `/boot`, `/proc`, `/sys`, and `/dev` on Linux and macOS). Symbolic links are resolved before these checks, and duplicate directories are removed (case-insensitively on Windows). + +| Variable | Toolchain | Value | Typically set on | +|----------|-----------|-------|------------------| +| `PATH` / `Path` | Executables (all) | Path list | All | +| `PYTHONPATH` | Python | Path list | All | +| `PYTHONHOME` | Python | Single directory | All | +| `VIRTUAL_ENV` | Python (venv) | Single directory | All | +| `PYENV_ROOT` | Python (pyenv) | Single directory | All | +| `CONDA_PREFIX` | Conda | Single directory | All | +| `GOPATH` | Go | Path list | All | +| `GOROOT` | Go | Single directory | All | +| `CARGO_HOME` | Rust (Cargo) | Single directory | All | +| `RUSTUP_HOME` | Rust (rustup) | Single directory | All | +| `JAVA_HOME` | Java | Single directory | All | +| `NODE_PATH` | Node.js | Path list | All | +| `NVM_HOME` | Node.js (nvm) | Single directory | Windows | +| `NVM_SYMLINK` | Node.js (nvm) | Single directory | Windows | +| `DOTNET_ROOT` | .NET | Single directory | All | +| `PSModulePath` | PowerShell | Path list | All | +| `VCINSTALLDIR` | Visual C++ | Single directory | Windows | +| `VSINSTALLDIR` | Visual Studio | Single directory | Windows | +| `VCPKG_ROOT` | vcpkg | Single directory | All | +| `LD_LIBRARY_PATH` | Shared libraries | Path list | Linux | + +Every variable is read on every platform; the **Typically set on** column shows where each is normally populated, not a restriction the CLI enforces. A variable that is unset simply contributes nothing. + +These are not the only read-only grants. {% data variables.copilot.copilot_cli_short %} also grants your user-profile application directories (`~/.local/bin` and `~/.local/lib` on Linux and macOS; the immediate subdirectories of `%LOCALAPPDATA%\Programs` on Windows), standard system and profile locations, and the caches and registries used by common package managers and toolchains (shown as **dev-tool access** in the `/sandbox policy` report). To see the fully resolved policy for your current directory—read/write, read-only, and denied paths—run `/sandbox policy` in a session. For the concepts behind how the policy is assembled, see [AUTOTITLE](/copilot/concepts/agents/copilot-cli/understanding-local-sandboxing). + ## OpenTelemetry monitoring {% data variables.copilot.copilot_cli_short %} can export traces and metrics via [OpenTelemetry](https://opentelemetry.io/) (OTel), giving you visibility into agent interactions, LLM calls, tool executions, and token usage. All signal names and attributes follow the [OTel GenAI Semantic Conventions](https://github.com/open-telemetry/semantic-conventions-genai/tree/main/docs/gen-ai/). @@ -1231,7 +1267,7 @@ OTel is off by default with zero overhead. It activates when any of the followin * `OTEL_EXPORTER_OTLP_ENDPOINT` is set * `COPILOT_OTEL_FILE_EXPORTER_PATH` is set -OTel configuration can also be set in {% data variables.product.prodname_vscode_shortname %}, or in an enterprise-wide `{% data variables.copilot.managed_setting_file %}` file. See [Enable OTel monitoring](https://code.visualstudio.com/docs/agents/guides/monitoring-agents#_enable-otel-monitoring) in the {% data variables.product.prodname_vscode_shortname %} documentation and [AUTOTITLE](/copilot/reference/enterprise-managed-settings-reference). +OTel configuration can also be set in {% data variables.product.prodname_vscode_shortname %}, or in an enterprise-wide `{% data variables.copilot.managed_setting_file %}` file. See [Enable OTel monitoring](https://code.visualstudio.com/docs/agents/guides/monitoring-agents#_enable-otel-monitoring) in the {% data variables.product.prodname_vscode_shortname %} documentation and [AUTOTITLE](/copilot/reference/enterprise-administrators/enterprise-managed-settings). ### OTel environment variables diff --git a/content/copilot/reference/copilot-usage-metrics/interpret-copilot-metrics.md b/content/copilot/reference/copilot-usage-metrics/interpret-copilot-metrics.md index a8c7f347db83..a969e29f6c02 100644 --- a/content/copilot/reference/copilot-usage-metrics/interpret-copilot-metrics.md +++ b/content/copilot/reference/copilot-usage-metrics/interpret-copilot-metrics.md @@ -98,8 +98,3 @@ Use trends in usage, feature adoption, and language activity to guide enablement > [!TIP] > Consider combining dashboard trends with feedback from surveys or retrospectives to get a full picture of {% data variables.product.prodname_copilot_short %}’s impact on developer productivity. - -## Next steps - -* To access metrics programmatically, including enterprise, organization, repository, and user-level records, see [AUTOTITLE](/rest/copilot/copilot-usage-metrics). -* To construct team-level metrics from the per-user usage metrics report, see [AUTOTITLE](/copilot/reference/copilot-usage-metrics/team-level-metrics). diff --git a/content/copilot/tutorials/roll-out-at-scale/index.md b/content/copilot/tutorials/roll-out-at-scale/index.md index 555aaa57f4c2..1fc77ccd6b45 100644 --- a/content/copilot/tutorials/roll-out-at-scale/index.md +++ b/content/copilot/tutorials/roll-out-at-scale/index.md @@ -9,6 +9,7 @@ children: - /govern-at-scale - /enable-developers - /drive-downstream-impact + - /measure-copilot-impact - /measure-success redirect_from: - /copilot/rolling-out-github-copilot-at-scale diff --git a/content/copilot/tutorials/roll-out-at-scale/measure-copilot-impact.md b/content/copilot/tutorials/roll-out-at-scale/measure-copilot-impact.md new file mode 100644 index 000000000000..1263b192cab1 --- /dev/null +++ b/content/copilot/tutorials/roll-out-at-scale/measure-copilot-impact.md @@ -0,0 +1,43 @@ +--- +title: Measure and demonstrate the impact of GitHub Copilot +shortTitle: '{% data variables.product.prodname_copilot_short %} usage metrics' +allowTitleToDifferFromFilename: true +intro: 'Understanding how {% data variables.product.prodname_copilot_short %} is used across your enterprise is the first step to demonstrating its value. Follow this path to establish a usage baseline, see how code is being generated, and connect adoption to measurable outcomes.' +layout: journey-landing +versions: + feature: copilot +contentType: tutorials +audience: + - driver +category: + - Copilot usage metrics + - Roll Copilot out at scale + - Manage Copilot for a team +journeyArticlesHeading: 'All Copilot usage metrics articles' +journeyTracks: + - id: 'get-started' + title: 'Phase 1: Choose metrics to monitor Copilot adoption.' + description: 'Understand what Copilot usage metrics measure and where the data comes from before you start monitoring adoption. Review the concepts behind usage metrics and the data available through the dashboard and API.' + guides: + - href: '/copilot/concepts/copilot-usage-metrics/copilot-metrics' + - href: '/copilot/reference/copilot-usage-metrics/copilot-usage-metrics' + - id: 'monitor-usage' + title: 'Phase 2: Monitor usage and adoption' + description: 'Establish a usage baseline, compare active users with assigned licenses, and identify where teams may need more support to adopt Copilot.' + guides: + - href: '/copilot/how-tos/administer-copilot/view-usage-and-adoption' + - href: '/copilot/tutorials/roll-out-at-scale/assign-licenses/track-usage-and-adoption' + - href: '/copilot/reference/copilot-usage-metrics/interpret-copilot-metrics' + - id: 'code-generation' + title: 'Phase 3: See how code is generated' + description: 'Review code generation and Lines of Code metrics to understand how people and agents are using Copilot to produce code.' + guides: + - href: '/copilot/how-tos/administer-copilot/view-code-generation' + - href: '/copilot/reference/copilot-usage-metrics/lines-of-code-metrics' + - id: 'connect-impact' + title: 'Phase 4: Connect adoption insights to engineering outcomes' + description: 'Define the engineering outcomes you want to improve and choose metrics that show progress. Compare adoption insights with metrics from your engineering systems to identify associations and evaluate results.' + guides: + - href: '/copilot/tutorials/roll-out-at-scale/drive-downstream-impact/achieve-company-goals' + - href: '/copilot/how-tos/administer-copilot/view-impact-dashboard' +--- diff --git a/data/release-notes/enterprise-server/3-22/0-rc1.yml b/data/release-notes/enterprise-server/3-22/0-rc1.yml index fa39b8e58c18..c755114d6c0f 100644 --- a/data/release-notes/enterprise-server/3-22/0-rc1.yml +++ b/data/release-notes/enterprise-server/3-22/0-rc1.yml @@ -1,4 +1,4 @@ -date: '2026-07-08' +date: '2026-08-11' release_candidate: true deprecated: false intro: | diff --git a/src/ghes-releases/scripts/deprecate/create-docs-ghes-version-repo.sh b/src/ghes-releases/scripts/deprecate/create-docs-ghes-version-repo.sh index 4da26fb9bb11..76f7be8ef6d9 100755 --- a/src/ghes-releases/scripts/deprecate/create-docs-ghes-version-repo.sh +++ b/src/ghes-releases/scripts/deprecate/create-docs-ghes-version-repo.sh @@ -4,6 +4,16 @@ version=$1 cd ~/Documents/gh/github + +# Teams are addressed by numeric ID because IDs survive team renames and slugs do not. +# Some APIs (repo creation, CODEOWNERS, custom properties) only accept slugs, so +# resolve the current slug from the ID at runtime rather than hardcoding it. +org_id=9919 +docs_team_id=325922 +docs_eng_team_id=3935808 +docs_team=$(gh api "/organizations/$org_id/team/$docs_team_id" --jq .slug) +docs_eng_team=$(gh api "/organizations/$org_id/team/$docs_eng_team_id" --jq .slug) + echo "--- Creating repository for github/docs-ghes-$version" echo "--- gh repo create" gh repo create \ @@ -15,7 +25,7 @@ gh repo create \ --disable-wiki \ --license="CC-BY-4.0" \ --private \ - --team="docs-engineering" \ + --team="$docs_eng_team" \ --homepage="https://github.github.com/docs-ghes-$version/" echo "--- gh repo edit" gh repo edit \ @@ -27,8 +37,8 @@ gh repo edit \ --enable-projects=false \ --enable-merge-commit=false \ --enable-rebase-merge=false -echo "--- github/docs-engineering as admin" -gh api -X PUT "/orgs/github/teams/docs-engineering/repos/github/docs-ghes-$version" \ +echo "--- github/$docs_eng_team as admin" +gh api -X PUT "/organizations/$org_id/team/$docs_eng_team_id/repos/github/docs-ghes-$version" \ -f 'permission=admin' --silent echo "--- github/employees as read" gh api -X PUT "/orgs/github/teams/employees/repos/github/docs-ghes-$version" --silent @@ -66,7 +76,7 @@ gh api -X POST "/repos/github/docs-ghes-$version/pages" \ echo "--- Update custom properties" gh api --method PATCH /repos/github/docs-ghes-$version/properties/values \ -f "properties[][property_name]=ownership-name" \ - -f "properties[][value]=@github/docs" \ + -f "properties[][value]=@github/$docs_team" \ -f "properties[][property_name]=ownership-type" \ -f "properties[][value]=Team" \ --silent @@ -74,7 +84,7 @@ echo "--- FILE UPDATES" cd "docs-ghes-$version" echo "--- docs engineering as codeowners" touch CODEOWNERS -echo "* @github/docs-engineering" > CODEOWNERS +echo "* @github/$docs_eng_team" > CODEOWNERS echo "--- add index.html file" touch index.html echo "

GitHub Enterprise Server $version Docs

" > index.html diff --git a/src/landings/components/ProductSelectionCard.module.scss b/src/landings/components/ProductSelectionCard.module.scss index ccd73bf99076..9247df9b41a6 100644 --- a/src/landings/components/ProductSelectionCard.module.scss +++ b/src/landings/components/ProductSelectionCard.module.scss @@ -63,7 +63,7 @@ .linkList { display: flex; flex-direction: column; - gap: 0.75rem; + gap: 0.25rem; margin: 0; padding: 0; list-style: none; @@ -78,7 +78,7 @@ overflow: hidden; font-size: 1rem; font-weight: 500; - line-height: 1rem; + line-height: 1.5; letter-spacing: 0.01rem; white-space: nowrap; text-overflow: ellipsis;