diff --git a/content/actions/reference/security/index.md b/content/actions/reference/security/index.md index d1d1822f422a..690a0c84ecfe 100644 --- a/content/actions/reference/security/index.md +++ b/content/actions/reference/security/index.md @@ -8,6 +8,7 @@ versions: ghec: '*' children: - /secure-use + - /securely-using-pull_request_target - /secrets - /oidc contentType: reference diff --git a/content/actions/reference/security/secure-use.md b/content/actions/reference/security/secure-use.md index 3d97018b65a6..55f8b467c299 100644 --- a/content/actions/reference/security/secure-use.md +++ b/content/actions/reference/security/secure-use.md @@ -106,8 +106,6 @@ For more information, see [AUTOTITLE](/code-security/code-scanning/introduction- To help mitigate the risk of an exposed token, consider restricting the assigned permissions. For more information, see [AUTOTITLE](/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token). -{% ifversion custom-org-roles %} - ## Mitigating the risks of untrusted code checkout Similar to script injection attacks, untrusted pull request content that automatically triggers actions processing can also pose a security risk. The `pull_request_target` and `workflow_run` workflow triggers, when used with the checkout of an untrusted pull request, expose the repository to security compromises. These workflows are privileged, which means they share the same cache of the main branch with other privileged workflow triggers, and may have repository write access and access to referenced secrets. These vulnerabilities can be exploited to take over a repository. @@ -116,6 +114,8 @@ For more information on these triggers, how to use them, and the associated risk For additional examples and guidance on the risks of untrusted code checkout, see [Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/) from {% data variables.product.prodname_security %} and the [Dangerous-Workflow](https://github.com/ossf/scorecard/blob/main/docs/checks.md#dangerous-workflow) documentation from OpenSSF Scorecard. +For detailed guidance on deciding whether to use `pull_request_target`, hardening these workflows, and opting out of the `actions/checkout` protection, see [AUTOTITLE](/actions/reference/security/securely-using-pull_request_target). + ### Good practices * Avoid using the `pull_request_target` workflow trigger if it's not necessary. For privilege separation between workflows, `workflow_run` is a better trigger. Only use these workflow triggers when the workflow actually needs the privileged context. @@ -126,8 +126,6 @@ For additional examples and guidance on the risks of untrusted code checkout, se * OpenSSF Scorecards can help you identify potentially vulnerable workflows, along with other security risks when using {% data variables.product.prodname_actions %}. See [Using OpenSSF Scorecards to secure workflow dependencies](#using-openssf-scorecards-to-secure-workflow-dependencies) later in this article. -{% endif %} - ## Using third-party actions The individual jobs in a workflow can interact with (and compromise) other jobs. For example, a job querying the environment variables used by a later job, writing files to a shared directory that a later job processes, or even more directly by interacting with the Docker socket and inspecting other running containers and executing commands in them. diff --git a/content/actions/reference/security/securely-using-pull_request_target.md b/content/actions/reference/security/securely-using-pull_request_target.md new file mode 100644 index 000000000000..9647e460c197 --- /dev/null +++ b/content/actions/reference/security/securely-using-pull_request_target.md @@ -0,0 +1,86 @@ +--- +title: Securely using pull_request_target +shortTitle: Securely using pull_request_target +intro: Learn about the security risks of the `pull_request_target event`. +versions: + fpt: '*' + ghes: '*' + ghec: '*' +contentType: reference +category: + - Secure your workflows +--- + +This guide helps you assess whether your workflow should use the `pull_request_target` event and understand the security risks involved. It also explains the protection {% data variables.product.github %} applies to [`actions/checkout`](https://github.com/actions/checkout) v7 and later to reduce these risks by default, and when to opt out of that protection if necessary. + +Read [`pull_request_target`](/actions/reference/workflows-and-actions/events-that-trigger-workflows#pull_request_target) before you check out pull request code from one of these workflows, or before you set the `allow-unsafe-pr-checkout` input on `actions/checkout`. + +## The risks of the pull_request_target event + +Workflows triggered by `pull_request_target` run with elevated trust: the job receives the base repository's `GITHUB_TOKEN`, access to repository and organization secrets, and write access to the default-branch cache. This is the same trust given to events like `push` that only collaborators can trigger, and it is what makes `pull_request_target` useful for automation that responds to pull requests from forks, such as labeling, triage, or for posting authenticated status checks. + +To understand why this is safe by default, and how that safety is commonly broken, review `pull_request_target` against [`pull_request`](/actions/reference/workflows-and-actions/events-that-trigger-workflows#pull_request). + +The `pull_request` event (along with `pull_request_review` and `pull_request_review_comment`) is unusual: it runs the workflow file from the **merge commit of the pull request**. For a pull request opened from a fork, that commit is controlled by someone without write access to the base repository. To run untrusted workflow code safely, {% data variables.product.github %} restricts these events to a read-only `GITHUB_TOKEN`, withholds access to other secrets, and applies fork approval policies to prevent compute abuse. For more information, see [AUTOTITLE](/actions/reference/workflows-and-actions/events-that-trigger-workflows#pull_request). By default, `actions/checkout` in a `pull_request` workflow also checks out the pull request's merge commit, so the code checked out and the workflow that runs are consistent. + +`pull_request_target` makes one critical and subtle change: the workflow, and any subsequent `actions/checkout` call that does not specify a `ref`, is taken from the **base repository's default branch**, not from the pull request. Because only trusted code from the default branch runs, it is safe to grant secrets and a read/write token. No code from the fork is executed by default. + +You introduce risk when a workflow author overrides this default to run the fork's code. Developers frequently choose `pull_request_target` because they want to run a fork's pull request through CI _and_ have access to secrets, for example to run tests that need a private registry. To do this, they point `actions/checkout` at the pull request head instead of the default branch, which is insecure: + +```yaml +# INSECURE. Provided as an example only. +on: + pull_request_target: + +jobs: + build: + runs-on: ubuntu-latest + steps: + - uses: {% data reusables.actions.action-checkout %} + with: + ref: {% raw %}${{ github.event.pull_request.head.sha }}{% endraw %} + - name: Test + run: make test +``` + +The checkout step alone does not execute untrusted code. The workflow file itself still comes from the default branch. The vulnerability is completed by the _next_ step that runs code checked out into the current working directory. Here, `make test` executes a `Makefile` taken from the pull request head. An attacker only needs to open a pull request from a fork whose `Makefile` (or build script, test command, dependency, or configuration file) contains malicious commands. Those commands then run with the base repository's secrets and token. + +This pattern is known as a "pwn request" and has been the root cause of multiple supply-chain compromises. For more information, see [Preventing pwn requests](https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/) from the {% data variables.product.prodname_security %}. Common vulnerable shapes include: + +* Checking out a pull request's head or merge commit in `actions/checkout` (`ref: {% raw %}${{ github.event.pull_request.head.sha }}{% endraw %}`, `ref: refs/pull/{% raw %}${{ github.event.pull_request.number }}{% endraw %}/merge`) and then building, testing, or otherwise executing the result. +* Setting `repository:` to the fork (`repository: {% raw %}${{ github.event.pull_request.head.repo.full_name }}{% endraw %}`) to pull the fork's branch directly. +* Fetching the pull request code outside of `actions/checkout` (for example with `git fetch`, `gh pr checkout`, or by downloading an artifact from a fork's `pull_request` run) and then running it. + +Pwn requests are also not unique to `pull_request_target`. Any event that runs with secrets can introduce a pwn request if it checks out or downloads and executes untrusted code. For example, an `issue_comment` or `workflow_run` workflow that fetches and runs a fork's pull request code is vulnerable in the same way. A `workflow_run` workflow should treat artifacts uploaded by other workflows as untrusted data, since their contents can come from a fork. + +## Deciding whether to use pull_request_target + +Some workflows need to check out fork pull request code with elevated trust, and this is why `pull_request_target` was created in the first place. For example, generating coverage reports that require a private artifact registry or producing and running authenticated checks against the changes introduced from the pull request. Consider the questions below before using `pull_request_target` or opting into the `allow-unsafe-pr-checkout` flag in `actions/checkout`. + +* **Can you use `pull_request` instead?** `pull_request` triggers on the same events as `pull_request_target` and runs the workflow code from the `pull_request` merge branch. It does this safely on pull requests from forks with the protections detailed above. If additional secret access is not needed, use `pull_request`. More complex workflows can be restructured to separate potentially dangerous handling of pull request code from accessing secrets. For more information, see [Preventing pwn requests](https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/#preventing-pwn-requests) from the {% data variables.product.prodname_security %}. + +* **Is the checked-out code ever executed?** This is the flaw that introduces pwn request vulnerabilities. It is most commonly introduced with `actions/checkout` by checking out a pull request head into the working directory and then running it. Unless the `path` input is set, `actions/checkout` writes the code into the `$GITHUB_WORKSPACE` directory, which is typically the working directory where subsequent commands run. Execution is not limited to your own steps: build and test commands such as `npm install` and `npm run build`, as well as configuration files and dependencies the code brings with it, can all run attacker-controlled code. Execution does not require an obvious build step. **You must ensure the checked-out code is only ever inspected as data and never executed before using a `pull_request_target` event**. + +## Hardening a pull_request_target workflow + +If you have confirmed you need `pull_request_target`, apply these controls to limit the impact of this high-risk event. These apply whether or not your workflow checks out pull request code. + +* **Restrict secrets.** Confirm that the permissions set on the `GITHUB_TOKEN` have the least privileges and that only the necessary repository and organization secrets are used for the workflow. For more information, see [AUTOTITLE](/actions/tutorials/authenticate-with-github_token#modifying-the-permissions-for-the-github_token). + +* **Understand the impact to caching.** Outside of the `GITHUB_TOKEN` and configured secrets, workflows that run on `pull_request_target` also have write access to the cache shared with other workflows on the default branch. Malicious changes to this cache from `pull_request_target` events could impact the execution of other, unrelated, workflows. + +* **Ensure the underlying compute is isolated and ephemeral.** If self-hosted runners are used, you must confirm that the runner environment is properly restricted from internal resources and is not reused across {% data variables.product.prodname_actions %} runs. For more information, see [AUTOTITLE](/actions/reference/security/secure-use#hardening-for-self-hosted-runners). + +* **Gate runs behind approval.** `pull_request_target` workflows can be gated behind a required `label` that only users with write access can add. This is detailed in the {% data variables.product.prodname_security %} [guidance on preventing pwn requests](https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/#preventing-pwn-requests). + +* **Enforce {% data variables.product.prodname_actions %} security best practices.** In addition to the specific risks of pwn requests, other common vulnerabilities, such as command injection, can exist and impact the code executed in this privileged event. For more information, see [Keeping your GitHub Actions and workflows secure: Untrusted input](https://securitylab.github.com/resources/github-actions-untrusted-input/) from the {% data variables.product.prodname_security %}. To identify and proactively protect against common {% data variables.product.prodname_actions %} vulnerabilities, enable {% data variables.product.prodname_codeql %} for {% data variables.product.prodname_actions %}. For more information, see [AUTOTITLE](/code-security/how-tos/find-and-fix-code-vulnerabilities/configure-code-scanning/configure-code-scanning). + +## Opting out of built-in protections + +If you have worked through the questions above and confirmed your workflow requires `pull_request_target` and uses it safely, you can opt out of the `actions/checkout` protection. Setting `allow-unsafe-pr-checkout: true` as an `actions/checkout` input allows checking out pull request head refs from forks. Only do this after confirming the checked-out code is never executed. The input is intentionally named to be easy to spot in code review and static analysis. + +This protection only covers fork pull request refs. Checking out other untrusted code, such as an unrelated third-party repository, fetching code with `git fetch` or `gh pr checkout`, or running a downloaded artifact, is not covered by the `actions/checkout` checks. + +## Restricting the use of pull_request_target + +Repository, organization, and enterprise administrators can use Workflow execution protections to control which events and actors can trigger workflows. If a repository has no legitimate use for `pull_request_target`, restricting it removes the risk regardless of how individual workflows are written. diff --git a/content/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities.md b/content/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities.md index 5b2f016f79ec..bbb744db633e 100644 --- a/content/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities.md +++ b/content/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities.md @@ -679,6 +679,24 @@ To show the full hook payload, result, and any exceptions for the delivery: ghe-webhook-logs -g DELIVERY_GUID ``` +## Backup and restore + +### ghe-backup-prune-snapshots + +This utility prunes old or invalid backup snapshot directories. + +```shell +ghe-backup-prune-snapshots +``` + +### ghe-backup-healthcheck + +This utility quickly confirms that GHES backups are being written, are recent, and that the backup disk is not in a risky state. For example, if usage is 90% or higher, it reports an error because the backup disk may be close to full. Setting `-no-color` gives plain text output, for example in logs or monitoring systems. + +```shell +ghe-backup-healthcheck +``` + ## Clustering ### ghe-cluster-balance diff --git a/content/admin/backing-up-and-restoring-your-instance/backup-service-for-github-enterprise-server/backup-service-settings-reference.md b/content/admin/backing-up-and-restoring-your-instance/backup-service-for-github-enterprise-server/backup-service-settings-reference.md index 1d1478a86eff..7878addc43a7 100644 --- a/content/admin/backing-up-and-restoring-your-instance/backup-service-for-github-enterprise-server/backup-service-settings-reference.md +++ b/content/admin/backing-up-and-restoring-your-instance/backup-service-for-github-enterprise-server/backup-service-settings-reference.md @@ -15,6 +15,9 @@ You can configure the following options in the "Backup Service" section of the { * **Number of snapshots**: Sets how many backup snapshots to retain (default: `10`). Older snapshots are automatically pruned after each successful backup. +> [!NOTE] +> You can run the `ghe-backup-prune-snapshots` utility to prune old and invalid snapshots manually. + ## Restore options * **Skip audit logs restore**: Excludes audit logs during a restore. diff --git a/content/admin/installing-your-enterprise-server/setting-up-a-github-enterprise-server-instance/installing-github-enterprise-server-on-vmware.md b/content/admin/installing-your-enterprise-server/setting-up-a-github-enterprise-server-instance/installing-github-enterprise-server-on-vmware.md index 5381d7fec797..5a1260400ad1 100644 --- a/content/admin/installing-your-enterprise-server/setting-up-a-github-enterprise-server-instance/installing-github-enterprise-server-on-vmware.md +++ b/content/admin/installing-your-enterprise-server/setting-up-a-github-enterprise-server-instance/installing-github-enterprise-server-on-vmware.md @@ -24,6 +24,9 @@ category: ## Hardware considerations +>[!NOTE] +>The root disk defaults to 200 GB. For non-cluster topologies, we recommend increasing it to 400 GB by updating the disk attributes in the OVF template before deployment. + {% data reusables.enterprise_installation.hardware-considerations-all-platforms %} ## Downloading the {% data variables.product.prodname_ghe_server %} image diff --git a/content/copilot/tutorials/optimize-ai-usage.md b/content/copilot/tutorials/optimize-ai-usage.md index 9189a5c2cd18..d054b0e45cc1 100644 --- a/content/copilot/tutorials/optimize-ai-usage.md +++ b/content/copilot/tutorials/optimize-ai-usage.md @@ -1,7 +1,7 @@ --- -title: Improving agent quality to optimize AI usage +title: Optimizing your AI usage to maximize efficiency and reduce cost shortTitle: Optimize AI usage -intro: 'Learn strategies for building higher-quality agents that complete tasks in fewer attempts and, as a result, use fewer {% data variables.product.prodname_ai_credits_short %}.' +intro: 'Learn how to choose the right models, structure your prompts, and add guardrails so that {% data variables.product.prodname_copilot_short %} completes tasks more efficiently and uses fewer {% data variables.product.prodname_ai_credits_short %}.' versions: feature: copilot contentType: tutorials @@ -11,13 +11,15 @@ category: ## Introduction -When agents are well-scoped, well-instructed, and operating within clear guardrails, token efficiency improves as a natural outcome. High-quality agents complete tasks in fewer attempts, follow clearer workflows with less rework, and avoid expensive debugging and correction cycles. - -Follow the strategies outlined in this article to improve both agent quality and {% data variables.product.prodname_ai_credits_short %} efficiency. +The strategies outlined in this article show you how to improve {% data variables.product.prodname_copilot_short %} efficiency and, as a result, use fewer {% data variables.product.prodname_ai_credits_short %}. ## 1. Choose the right model for the right task -Model choice is one of the fastest ways to improve both agent quality and cost efficiency, but it is often overlooked. A common pattern is to default to the most capable model for every task—but this often increases token usage without improving the outcome. In some execution-heavy scenarios, overusing reasoning models can reduce quality because the model may overthink the task or introduce unnecessary changes. +By selecting the right capability level for your task, configuring reasoning appropriately, and leveraging {% data variables.copilot.copilot_auto_model_selection_short %} and cheaper models for specific workloads, you can maintain quality while significantly reducing token consumption. + +### Select the right model + +Model choice is one of the fastest ways to improve cost efficiency, but it is often overlooked. A common pattern is to default to the most capable model for every task—but this often increases token usage without improving the outcome. In some execution-heavy scenarios, overusing reasoning models can reduce quality because the model may overthink the task or introduce unnecessary changes. Choose the model based on the work involved: @@ -35,11 +37,23 @@ Some models also support configurable reasoning levels, which control how much t See [AUTOTITLE](/copilot/reference/ai-models/supported-models#models-with-extended-capabilities). -### Use {% data variables.copilot.copilot_auto_model_selection %} +### Use {% data variables.copilot.copilot_auto_model_selection %} as your default + +{% data variables.copilot.copilot_auto_model_selection_short_cap_a %} chooses a capable model for you, based on the intent of your task. + +A small router looks at your prompt and sends it to the model that can **handle it most efficiently**, reserving expensive reasoning models for complex problems. It also avoids models that burn through a token budget quickly. + +{% data variables.copilot.copilot_auto_model_selection_short_cap_a %} also **protects your cache**. It only changes models at natural cache boundaries, when a new session starts or after you run `/compact`, never mid-task. To understand more about why this matters, see [4. Preserve the cache](#4-preserve-the-cache). -{% data variables.copilot.copilot_auto_model_selection %} chooses a capable model for you, based on the intent of your task. +{% data variables.copilot.copilot_auto_model_selection_short_cap_a %} also routes around degraded or busy models, so you hit fewer rate limits and errors. -See [AUTOTITLE](/copilot/concepts/models/auto-model-selection). +{% data reusables.copilot.auto-model-discount %} + +For information on the feature and its availability, see [AUTOTITLE](/copilot/concepts/models/auto-model-selection#copilot-chat-in-ides). + +### Use cheaper models for {% data variables.copilot.subagents_short %} + +Run {% data variables.copilot.subagents_short %} on cheaper models. {% data variables.copilot.subagents_caps_short %} run in their own session and don't inherit the main agent's conversation history. Because their context is scoped to a single focused task, a lighter model is often sufficient—and assigning one doesn't affect the main agent's cache the way a mid-session model switch would. ## 2. Provide clear guidance in your prompts @@ -86,15 +100,52 @@ Large tool sets (for example, a full MCP server's worth of tools) add to the con See [AUTOTITLE](/copilot/how-tos/provide-context/use-mcp-in-your-ide/configure-toolsets). -### Take advantage of context caching +## 4. Preserve the cache + +Caching lets an AI model store portions of a conversation's context so they don't need to be reprocessed on every request. In agentic coding, where the same large context—system prompt, file contents, tool definitions—is sent repeatedly across many turns, caching has an impact: the cached portion from the previous response is reused rather than reprocessed, and cached tokens are typically billed at 10% of the normal input price. See [AUTOTITLE](/copilot/reference/copilot-billing/models-and-pricing). + +However, the following actions invalidate the cache, causing the full context to be re-sent and billed as fresh input tokens: + +* **Switching models mid-session**. A different model can't reuse another model's cache, so the next request rebuilds it from scratch. Pick a model (or use {% data variables.copilot.copilot_auto_model_selection %}) and stick with it for the session. +* **Coming back to an old session**. Caches expire after a period of inactivity (24 hours for OpenAI models and 1 hour for most others). If you've been away a while, start a new session, or run `/compact` (in {% data variables.copilot.copilot_cli_short %}) so what gets rebuilt is a short summary rather than the full history. +* **Changing reasoning mid-session**. Changing the reasoning effort level, context size, or the set of enabled tools and MCP servers during a session invalidates the cache. Configure these settings before you start and leave them unchanged for the session. + +## 5. Research, plan, then implement + +One of the biggest shifts in working effectively with agents is moving away from doing everything in a single session. When research, planning, and implementation all happen together, context grows quickly and irrelevant information accumulates. + +Break work into clear phases: + +* **Research:** Use the agent to explore the codebase, identify relevant files, and understand dependencies. +* **Plan:** Create a detailed, structured plan or specification before making changes. This is where reasoning models are most valuable—always plan with a strong reasoning model, then implement the work with a cheaper model. + * In {% data variables.copilot.copilot_cli_short %}, use `/plan`. + * In {% data variables.copilot.copilot_chat_short %} in {% data variables.product.prodname_vscode %}, select "Plan" from the agent dropdown, or type `plan` in the context window. +* **Implement:** Execute against the plan using focused context and a model suited for execution. + +Starting a new session between phases prevents you from carrying unnecessary context forward, which can increase token usage and reduce clarity for the agent. Each phase should operate with only what it needs. For guidance on scoping sessions effectively, see [AUTOTITLE](/copilot/tutorials/cloud-agent/get-the-best-results). + +## 6. Utilize learnings to be more efficient at every turn + +### Use `/chronicle` to generate insights -{% data variables.product.prodname_copilot_short %} reuses context you've already sent through caching, which lowers the cost of follow-up turns. However, cached context expires after a period of inactivity and isn't reused when you switch models mid-session. In both cases, the context is re-sent and billed again as fresh input tokens. To get the most from caching, keep related work in one continuous session and avoid switching models partway through. +In {% data variables.copilot.copilot_cli_short %}, `/chronicle` can generate useful insights from your session history. -## 4. Reduce repeated errors with a `copilot-instructions.md` file +* Use `/chronicle tips` to analyze your recent session history and surface opportunities to use {% data variables.product.prodname_copilot_short %} more efficiently. +* Use `/chronicle cost-tips` to understand your token usage patterns and get insights into how to reduce cost. -Persistent instructions improve consistency across agent interactions, but their value depends entirely on how they are written. A `copilot-instructions.md` file at the repository level is the most direct way to encode this guidance. Personal and organization-level instructions can layer on top for broader consistency. +See [AUTOTITLE](/copilot/concepts/agents/copilot-cli/chronicle#the-chronicle-slash-command). -The best instructions are short, specific, and grounded in real observed agent behavior—not generic best practices that sound good but don't apply to your system. +### Feed insights into a `copilot-instructions.md` file + +A `copilot-instructions.md` file at the repository level is the most direct way to encode guidance that's specific to your repository. Personal and organization-level instructions can layer on top for broader consistency. + +When `/chronicle` surfaces a recurring pattern—a tool being over-used, a prompt that keeps being misread—encode that observation directly in your `copilot-instructions.md` file. This turns a one-time insight into standing guidance that applies to every future session, without you having to repeat it. + +For more information, see [AUTOTITLE](/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions/add-repository-instructions). + +### Keep the `copilot-instructions.md` file specific and grounded + +Persistent instructions improve consistency across agent interactions, but their value depends entirely on how they are written. The best instructions are short, specific, and grounded in real observed agent behavior—not generic best practices that sound good but don't apply to your system. **What to include:** @@ -113,23 +164,7 @@ The best instructions are short, specific, and grounded in real observed agent b Keep instructions updated as your codebase, architecture, standards, and workflows evolve. Because these instructions are included in the agent's context on every run, even small improvements can reduce repeated errors and lower wasted token usage over time. -For more information, see [AUTOTITLE](/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions/add-repository-instructions). - -## 5. Research, plan, then implement - -One of the biggest shifts in working effectively with agents is moving away from doing everything in a single session. When research, planning, and implementation all happen together, context grows quickly, irrelevant information accumulates, and agent quality degrades over time. - -Break work into clear phases: - -* **Research:** Use the agent to explore the codebase, identify relevant files, and understand dependencies. -* **Plan:** Create a detailed, structured plan or specification before making changes. This is where reasoning models are most valuable. - * In {% data variables.copilot.copilot_cli_short %}, use `/plan`. - * In {% data variables.copilot.copilot_chat_short %} in {% data variables.product.prodname_vscode %}, select "Plan" from the agent dropdown, or type `plan` in the context window. -* **Implement:** Execute against the plan using focused context and a model suited for execution. - -Starting a new session between phases prevents carrying unnecessary context forward. Carrying forward context from earlier phases can increase token usage, introduce bias, and reduce clarity for the agent. Each phase should operate with only what it needs. For guidance on scoping sessions effectively, see [AUTOTITLE](/copilot/tutorials/cloud-agent/get-the-best-results). - -## 6. Add deterministic guardrails +## 7. Add deterministic guardrails Agents are non-deterministic and won't be correct every time, especially in multi-step workflows. Without guardrails, small errors can compound quickly: agents build on incorrect outputs, drift further from the goal, and make debugging more expensive and time-consuming. @@ -145,8 +180,7 @@ Teams that invest in these guardrails see fewer retries, faster task completion, ## Next steps -In addition to improving agent efficiency, you can also monitor and manage your spending to get the most out of your {% data variables.product.prodname_ai_credits_short %}: +Monitor and manage your spending to get the most out of your {% data variables.product.prodname_ai_credits_short %}: * **Use your dashboard and budget controls**. The "AI usage" page, under https://github.com/settings/billing, breaks down consumption across every feature and model, so you can see where your credits are actually going and adjust accordingly. See [AUTOTITLE](/copilot/how-tos/manage-and-track-spending/monitor-ai-usage). -* **Identify expensive patterns before they add up**. Within a {% data variables.copilot.copilot_cli_short %} session, use `/usage` to see session-level metrics and to spot expensive patterns as you work. In addition, `/chronicle tips` analyzes your recent session history and surfaces opportunities to use {% data variables.product.prodname_copilot_short %} more efficiently. * **Upgrade for a larger allowance**. If you regularly approach your monthly limit, a higher plan may be more economical than paying for additional usage, as higher plans have more {% data variables.product.prodname_ai_credit_singular %} allowance. See [AUTOTITLE](/copilot/concepts/billing/individual-plans#github-ai-credits-allowance-by-plan) and [AUTOTITLE](/copilot/how-tos/manage-your-account/view-and-change-your-copilot-plan). \ No newline at end of file diff --git a/content/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax.md b/content/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax.md index f695150c5b59..55823aacd9fd 100644 --- a/content/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax.md +++ b/content/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax.md @@ -360,6 +360,12 @@ When you mention a parent team, members of its child teams also receive notifica Typing an @ symbol will bring up a list of people or teams on a project. The list filters as you type, so once you find the name of the person or team you are looking for, you can use the arrow keys to select it and press either tab or enter to complete the name. For teams, enter the @organization/team-name and all members of that team will get subscribed to the conversation. +{% ifversion enterprise-teams-ga %} + +You can also mention an enterprise team. Enterprise team slugs use an `ent:` prefix in the format `@/ent:TEAM-SLUG`, for example `@/ent:platform-sre`. You can mention an enterprise team from any organization the team is assigned to. See [AUTOTITLE](/admin/concepts/enterprise-fundamentals/teams-in-an-enterprise). + +{% endif %} + The autocomplete results are restricted to repository collaborators and any other participants on the thread. ## Referencing issues and pull requests diff --git a/content/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners.md b/content/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners.md index 59cb9e1dfed0..3ea727ef5be6 100644 --- a/content/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners.md +++ b/content/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners.md @@ -63,6 +63,13 @@ To reduce the size of your CODEOWNERS file, consider using wildcard patterns to A CODEOWNERS file uses a pattern that follows most of the same rules used in [gitignore](https://git-scm.com/docs/gitignore#_pattern_format) files. The pattern is followed by one or more {% data variables.product.prodname_dotcom %} usernames or team names using the standard `@username` or `@org/team-name` format. Users and teams must have explicit `write` access to the repository, even if the team's members already have access. +{% ifversion enterprise-teams %} + +> [!NOTE] +> When using teams, only organization teams can be code owners. Enterprise teams are not supported as code owners. See [AUTOTITLE](/admin/concepts/enterprise-fundamentals/teams-in-an-enterprise). + +{% endif %} + If you want to match two or more code owners with the same pattern, all the code owners must be on the same line. If the code owners are not on the same line, the pattern matches only the last mentioned code owner. {% ifversion fpt or ghec %}In most cases, you{% else %}You{% endif %} can also refer to a user by an email address that has been added to their account, for example `user@example.com`. {% ifversion fpt or ghec %} You cannot use an email address to refer to a {% data variables.enterprise.prodname_managed_user %}. For more information about {% data variables.enterprise.prodname_managed_users %}, see [AUTOTITLE](/enterprise-cloud@latest/admin/identity-and-access-management/using-enterprise-managed-users-for-iam/about-enterprise-managed-users){% ifversion fpt %}" in the {% data variables.product.prodname_ghe_cloud %} documentation.{% else %}.{% endif %}{% endif %} diff --git a/data/features/app-key-limit.yml b/data/features/app-key-limit.yml deleted file mode 100644 index 2374bbb4b6c1..000000000000 --- a/data/features/app-key-limit.yml +++ /dev/null @@ -1,6 +0,0 @@ -# Reference: #https://github.com/github/docs-content/issues/15738 - -versions: - fpt: '*' - ghec: '*' - ghes: '>=3.17' diff --git a/data/features/dependabot-alerts-epss-score.yml b/data/features/dependabot-alerts-epss-score.yml deleted file mode 100644 index 0882571da8ce..000000000000 --- a/data/features/dependabot-alerts-epss-score.yml +++ /dev/null @@ -1,6 +0,0 @@ -# References: -# Issue #15659 - EPSS Scores for Dependabot Alerts [GA] -versions: - fpt: '*' - ghec: '*' - ghes: '>3.16' diff --git a/data/features/horizontal-nav.yml b/data/features/horizontal-nav.yml deleted file mode 100644 index e10f47dd42cb..000000000000 --- a/data/features/horizontal-nav.yml +++ /dev/null @@ -1,6 +0,0 @@ -# Reference: #17228 -# Move Enterprise navigation from left sidebar to top of page -versions: - fpt: '*' - ghec: '*' - ghes: '>3.16' diff --git a/data/features/pats-maximum-lifetime.yml b/data/features/pats-maximum-lifetime.yml deleted file mode 100644 index 5f551e6ff6d7..000000000000 --- a/data/features/pats-maximum-lifetime.yml +++ /dev/null @@ -1,6 +0,0 @@ -# Issue 8157 -# PATs (classic) and fine-grained PATs lifetime requirements policy -versions: - fpt: '*' - ghec: '*' - ghes: '>=3.17' diff --git a/data/features/persistent-commit-verification.yml b/data/features/persistent-commit-verification.yml deleted file mode 100644 index 294b0df37ca5..000000000000 --- a/data/features/persistent-commit-verification.yml +++ /dev/null @@ -1,7 +0,0 @@ -# Issue: 15674 -# Description: Once a commit signature is verified, it remains verified within its repository's network -# Usage: {% ifversion persistent-commit-verification %} ... {% endif %} -versions: - fpt: '*' - ghec: '*' - ghes: '>=3.17' diff --git a/data/features/secret-scanning-enable-by-default-for-public-repos.yml b/data/features/secret-scanning-enable-by-default-for-public-repos.yml deleted file mode 100644 index 09a8566a0ba4..000000000000 --- a/data/features/secret-scanning-enable-by-default-for-public-repos.yml +++ /dev/null @@ -1,5 +0,0 @@ -# Reference: #13800. -# Secret scanning is automatically enabled on all new public repositories - [GA] -versions: - fpt: '*' - ghec: '*' diff --git a/data/features/secret-scanning-generic-tab.yml b/data/features/secret-scanning-generic-tab.yml deleted file mode 100644 index 71a5534bffc0..000000000000 --- a/data/features/secret-scanning-generic-tab.yml +++ /dev/null @@ -1,5 +0,0 @@ -# Reference: #17438 - Rename the secret scanning "Experimental" tab to curb confusion on alert confidence [GA] -versions: - fpt: '*' - ghec: '*' - ghes: '>3.16' diff --git a/data/reusables/actions/pull-request-target-permissions-warning.md b/data/reusables/actions/pull-request-target-permissions-warning.md index dbb051021d60..3ff34c0e7f47 100644 --- a/data/reusables/actions/pull-request-target-permissions-warning.md +++ b/data/reusables/actions/pull-request-target-permissions-warning.md @@ -1,2 +1,2 @@ > [!WARNING] -> Running untrusted code on the `pull_request_target` trigger may lead to security vulnerabilities. These vulnerabilities include cache poisoning and granting unintended access to write privileges or secrets. For more information, see [AUTOTITLE](/enterprise-cloud@latest/actions/reference/security/secure-use#mitigating-the-risks-of-untrusted-code-checkout) in the {% data variables.product.prodname_ghe_cloud %} documentation, and [Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests) on the {% data variables.product.prodname_security %} website. +> Running untrusted code on the `pull_request_target` trigger may lead to security vulnerabilities. These vulnerabilities include cache poisoning and granting unintended access to write privileges or secrets. To learn how to use this trigger safely, see [AUTOTITLE](/actions/reference/security/securely-using-pull_request_target). For more details on the underlying risks, see [AUTOTITLE](/enterprise-cloud@latest/actions/reference/security/secure-use#mitigating-the-risks-of-untrusted-code-checkout) and [Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests) from {% data variables.product.prodname_security %}. diff --git a/data/reusables/enterprise-onboarding/about-teams.md b/data/reusables/enterprise-onboarding/about-teams.md index 276bb82e14e3..1902cd7a839b 100644 --- a/data/reusables/enterprise-onboarding/about-teams.md +++ b/data/reusables/enterprise-onboarding/about-teams.md @@ -35,10 +35,18 @@ Team sync with personal accounts is only available with organization teams, and To simplify administration at scale, {% data variables.product.company_short %} recommends using enterprise teams for any use cases that apply to the enterprise account or to multiple organizations. Organization teams are useful when the need for the team is scoped to a single organization and the team can be managed by an organization administrator. -You may need to create organization teams if the functionality you need is not covered by enterprise teams. {% data variables.product.company_short %} plans to address some limitations in the near future. +You may need to create organization teams if the functionality you need is not covered by enterprise teams. The limitations listed below reflect the current capabilities of enterprise teams and may change over time. {% data reusables.enterprise.enterprise-teams-can %} +{%- ifversion enterprise-teams-ga %} + +To @-mention an enterprise team, or request a review from the team, use the team's slug in the format `@/ent:TEAM-SLUG`. {% data variables.product.github %} generates the slug from the team's name and adds the `ent:` prefix, so an enterprise team named `Platform SRE` has the slug `ent:platform-sre`. + +To mention the team from an organization it is assigned to, such as `octo-org`, use `@octo-org/ent:platform-sre`. You can mention an enterprise team from any organization the team is assigned to. + +{%- endif %} + However, unlike organization teams, enterprise teams currently do **not** support: {%- ifversion enterprise-teams-ga %}