diff --git a/.github/workflows/needs-sme-stale-check.yaml b/.github/workflows/needs-sme-stale-check.yaml index 1ea9dd57f88f..67b8f237f02a 100644 --- a/.github/workflows/needs-sme-stale-check.yaml +++ b/.github/workflows/needs-sme-stale-check.yaml @@ -19,7 +19,7 @@ jobs: runs-on: ubuntu-latest steps: - - uses: actions/stale@3a9db7e6a41a89f618792c92c0e97cc736e1b13f # v10.0.0 + - uses: actions/stale@4391f3da665fdf50b6810c1a66712fb9ba21aa93 # v11.0.0 id: stale with: only-labels: needs SME diff --git a/.github/workflows/no-response.yaml b/.github/workflows/no-response.yaml index 040e06aef43a..2c43c14787e4 100644 --- a/.github/workflows/no-response.yaml +++ b/.github/workflows/no-response.yaml @@ -33,7 +33,7 @@ jobs: github.actor != 'github-actions' && !endsWith(github.actor, '[bot]') steps: - - uses: actions/stale@3a9db7e6a41a89f618792c92c0e97cc736e1b13f # v10.0.0 + - uses: actions/stale@4391f3da665fdf50b6810c1a66712fb9ba21aa93 # v11.0.0 id: stale with: repo-token: ${{ secrets.GITHUB_TOKEN }} diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml index 2c7bdd552866..d008aa8e812a 100644 --- a/.github/workflows/stale.yml +++ b/.github/workflows/stale.yml @@ -21,7 +21,7 @@ jobs: if: github.repository == 'github/docs-internal' runs-on: ubuntu-latest steps: - - uses: actions/stale@3a9db7e6a41a89f618792c92c0e97cc736e1b13f # v10.0.0 + - uses: actions/stale@4391f3da665fdf50b6810c1a66712fb9ba21aa93 # v11.0.0 id: stale with: repo-token: ${{ secrets.GITHUB_TOKEN }} diff --git a/.github/workflows/triage-stale-check.yml b/.github/workflows/triage-stale-check.yml index 139080ccf61f..7a081a9fc34e 100644 --- a/.github/workflows/triage-stale-check.yml +++ b/.github/workflows/triage-stale-check.yml @@ -21,7 +21,7 @@ jobs: pull-requests: write steps: - - uses: actions/stale@3a9db7e6a41a89f618792c92c0e97cc736e1b13f # v10.0.0 + - uses: actions/stale@4391f3da665fdf50b6810c1a66712fb9ba21aa93 # v11.0.0 with: repo-token: ${{ secrets.GITHUB_TOKEN }} days-before-stale: 30 @@ -60,7 +60,7 @@ jobs: issues: write pull-requests: write steps: - - uses: actions/stale@3a9db7e6a41a89f618792c92c0e97cc736e1b13f # v10.0.0 + - uses: actions/stale@4391f3da665fdf50b6810c1a66712fb9ba21aa93 # v11.0.0 id: stale with: repo-token: ${{ secrets.GITHUB_TOKEN }} diff --git a/content/actions/concepts/workflows-and-actions/reusing-workflow-configurations.md b/content/actions/concepts/workflows-and-actions/reusing-workflow-configurations.md index 264b5632c4a7..8080a1f5856e 100644 --- a/content/actions/concepts/workflows-and-actions/reusing-workflow-configurations.md +++ b/content/actions/concepts/workflows-and-actions/reusing-workflow-configurations.md @@ -20,6 +20,12 @@ contentType: concepts Rather than copying and pasting from one workflow to another, you can make workflows reusable. You and anyone with access to the reusable workflow can then call the reusable workflow from another workflow. +{% ifversion copilot %} + +Reusable workflows also complement {% data variables.copilot.agentic_workflows_short %}: an agentic workflow can call approved, deterministic reusable workflows rather than duplicating logic. For more information, see [AUTOTITLE](/copilot/how-tos/github-agentic-workflows/creating-github-agentic-workflows). + +{% endif %} + Reusing workflows avoids duplication. This makes workflows easier to maintain and allows you to create new workflows more quickly by building on the work of others, just as you do with actions. Workflow reuse also promotes best practice by helping you to use workflows that are well designed, have already been tested, and have been proven to be effective. Your organization can build up a library of reusable workflows that can be centrally maintained. The diagram below shows an in-progress workflow run that uses a reusable workflow. @@ -77,6 +83,12 @@ If you use a commit SHA when referencing the reusable workflow, you can ensure t For more information, see [AUTOTITLE](/actions/how-tos/reuse-automations/create-workflow-templates). +{% ifversion copilot %} + +Organizations can also share and govern approved {% data variables.copilot.agentic_workflows_short %} templates alongside shared actions and reusable workflows. To create templates with {% data variables.copilot.github_agentic_workflows %}, see [AUTOTITLE](/copilot/how-tos/github-agentic-workflows/creating-github-agentic-workflows). + +{% endif %} + {% ifversion fpt or ghec %} ## YAML anchors and aliases diff --git a/content/actions/get-started/continuous-deployment.md b/content/actions/get-started/continuous-deployment.md index 8bd59e8dffd3..f2e60c04f7d3 100644 --- a/content/actions/get-started/continuous-deployment.md +++ b/content/actions/get-started/continuous-deployment.md @@ -34,6 +34,13 @@ You can configure your CD workflow to run when an event occurs (for example, whe {% data variables.product.prodname_actions %} provides features that give you more control over deployments. For example, you can use environments to require approval for a job to proceed, restrict which branches can trigger a workflow, or limit access to secrets. You can use concurrency to limit your CD pipeline to a maximum of one in-progress deployment{% ifversion actions-nga %}{% else %} and one pending deployment{% endif %}. For more information about these features, see [AUTOTITLE](/actions/how-tos/deploy/configure-and-manage-deployments/control-deployments) and [AUTOTITLE](/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments). +{% ifversion copilot %} + +> [!TIP] +> You can use {% data variables.copilot.agentic_workflows_short %} for deployment preparation, such as release notes, change analysis, and rollout summaries, while keeping production deployments in deterministic {% data variables.product.prodname_actions %} workflows. For more information, see [AUTOTITLE](/copilot/how-tos/github-agentic-workflows/creating-github-agentic-workflows). + +{% endif %} + ## Workflow templates and third-party actions {% data reusables.actions.cd-templates-actions %} diff --git a/content/actions/get-started/understand-github-actions.md b/content/actions/get-started/understand-github-actions.md index badf3b244bed..d6014b3c1166 100644 --- a/content/actions/get-started/understand-github-actions.md +++ b/content/actions/get-started/understand-github-actions.md @@ -114,6 +114,13 @@ For more information{% ifversion fpt or ghec %} about self-hosted runners{% endi {% data reusables.actions.onboarding-next-steps %} +{% ifversion copilot %} + +> [!NOTE] +> For automations that require contextual judgment about your repository's content, you can also author {% data variables.copilot.agentic_workflows_short %} in natural language instead of a traditional {% data variables.product.prodname_actions %} workflow. For more information, see [AUTOTITLE](/copilot/how-tos/github-agentic-workflows/quickstart) and [AUTOTITLE](/copilot/how-tos/github-agentic-workflows/creating-github-agentic-workflows). + +{% endif %} + {% ifversion ghec or ghes %} ## Further reading diff --git a/content/actions/how-tos/manage-workflow-runs/manually-run-a-workflow.md b/content/actions/how-tos/manage-workflow-runs/manually-run-a-workflow.md index 5ff1665a49c5..e1d4787f8dea 100644 --- a/content/actions/how-tos/manage-workflow-runs/manually-run-a-workflow.md +++ b/content/actions/how-tos/manage-workflow-runs/manually-run-a-workflow.md @@ -93,3 +93,4 @@ When using the REST API, you configure the `inputs` and `ref` as request body pa > You can define up to {% ifversion fpt or ghec %}25 {% else %}10 {% endif %} `inputs` for a `workflow_dispatch` event. For more information about using the REST API, see [AUTOTITLE](/rest/actions/workflows#create-a-workflow-dispatch-event). + diff --git a/content/actions/reference/workflows-and-actions/events-that-trigger-workflows.md b/content/actions/reference/workflows-and-actions/events-that-trigger-workflows.md index ec2cf92f9231..0734cdc180c9 100644 --- a/content/actions/reference/workflows-and-actions/events-that-trigger-workflows.md +++ b/content/actions/reference/workflows-and-actions/events-that-trigger-workflows.md @@ -27,6 +27,12 @@ Some events have multiple activity types. For these events, you can specify whic > [!NOTE] > Not all webhook events trigger workflows. +{% ifversion copilot %} + +Like {% data variables.product.prodname_actions %} workflows, {% data variables.copilot.agentic_workflows_short %} can be triggered by repository events and schedules. For an example, see [AUTOTITLE](/copilot/how-tos/github-agentic-workflows/creating-github-agentic-workflows). + +{% endif %} + ## `branch_protection_rule` | Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` | @@ -376,7 +382,7 @@ on: > * {% data reusables.developer-site.multiple_activity_types %} Although only the `checks_requested` activity type is supported, specifying the activity type will keep your workflow specific if more activity types are added in the future. For information about each activity type, see [AUTOTITLE](/webhooks/webhook-events-and-payloads#merge_group). {% data reusables.developer-site.limit_workflow_to_activity_types %} > * {% data reusables.actions.merge-group-event-with-required-checks %} -Runs your workflow when a pull request is added to a merge queue, which adds the pull request to a merge group. For more information see [AUTOTITLE](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request-with-a-merge-queue). +Runs your workflow when a pull request is added to a merge queue, which adds the pull request to a merge group. For more information see [AUTOTITLE](/pull-requests/how-tos/merge-and-close-pull-requests/merging-a-pull-request-with-a-merge-queue). For example, you can run a workflow when the `checks_requested` activity has occurred. @@ -461,7 +467,7 @@ on: Runs your workflow when activity on a pull request in the workflow's repository occurs. For example, if no activity types are specified, the workflow runs when a pull request is opened or reopened or when the head branch of the pull request is updated. For activity related to pull request reviews, pull request review comments, or pull request comments, use the [`pull_request_review`](#pull_request_review), [`pull_request_review_comment`](#pull_request_review_comment), or [`issue_comment`](#issue_comment) events instead. For information about the pull request APIs, see [AUTOTITLE](/graphql/reference/pulls#object-pullrequest) in the GraphQL API documentation or [AUTOTITLE](/rest/pulls). -Note that `GITHUB_SHA` for this event is the last merge commit of the pull request merge branch. If you want to get the commit ID for the last commit to the head branch of the pull request, use `github.event.pull_request.head.sha` instead. For more information about merge branches, see [AUTOTITLE](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#pull-request-refs-and-merge-branches). +Note that `GITHUB_SHA` for this event is the last merge commit of the pull request merge branch. If you want to get the commit ID for the last commit to the head branch of the pull request, use `github.event.pull_request.head.sha` instead. For more information about merge branches, see [AUTOTITLE](/pull-requests/reference/pull-requests#pull-request-refs-and-merge-branches). ### How the merge branch affects your workflow @@ -1272,3 +1278,5 @@ jobs: body: 'Thank you for the PR!' }); ``` + + diff --git a/content/actions/reference/workflows-and-actions/reusing-workflow-configurations.md b/content/actions/reference/workflows-and-actions/reusing-workflow-configurations.md index 915a229e4188..e86273424c6e 100644 --- a/content/actions/reference/workflows-and-actions/reusing-workflow-configurations.md +++ b/content/actions/reference/workflows-and-actions/reusing-workflow-configurations.md @@ -16,8 +16,13 @@ contentType: reference ## Reusable workflows -Reference information for reusable workflows. +This article provides reference information for reusable workflows and workflow templates, including access rules, limitations, supported keywords, and runner behavior. +{% ifversion copilot %} + +You can centralize deterministic, repeatable logic in reusable workflows, and use {% data variables.copilot.agentic_workflows_short %} for tasks that require contextual judgment about your repository's content such as analysis, summaries, and recommendations. For more information, see [AUTOTITLE](/copilot/how-tos/github-agentic-workflows/creating-github-agentic-workflows). + +{% endif %} ### Access to reusable workflows A reusable workflow can be used by another workflow if any of the following is true: @@ -244,3 +249,4 @@ jobs: ``` {% endif %} + diff --git a/content/actions/reference/workflows-and-actions/workflow-syntax.md b/content/actions/reference/workflows-and-actions/workflow-syntax.md index 1d4a98add51b..7a97859281d0 100644 --- a/content/actions/reference/workflows-and-actions/workflow-syntax.md +++ b/content/actions/reference/workflows-and-actions/workflow-syntax.md @@ -28,6 +28,12 @@ Workflow files use YAML syntax, and must have either a `.yml` or `.yaml` file ex You must store workflow files in the `.github/workflows` directory of your repository. +{% ifversion copilot %} + +> [!TIP] +> Unlike traditional {% data variables.product.prodname_actions %} workflows that require you to script every decision as YAML job steps, {% data variables.copilot.github_agentic_workflows %} use YAML frontmatter for triggers and configuration, but let you describe what you want in natural-language Markdown—so you don't need to anticipate and encode every scenario in advance. For more information, see [AUTOTITLE](/copilot/how-tos/github-agentic-workflows/creating-github-agentic-workflows). + +{% endif %} ## `name` {% data reusables.actions.workflows.workflow-syntax-name %} @@ -1566,3 +1572,5 @@ Path patterns must match the whole path, and start from the repository's root. | `'**/migrate-*.sql'` | A file with the prefix `migrate-` and suffix `.sql` anywhere in the repository. | `migrate-10909.sql`

`db/migrate-v1.0.sql`

`db/sept/migrate-v1.sql` | | `'*.md'`

`'!README.md'` | Using an exclamation mark (`!`) in front of a pattern negates it. When a file matches a pattern and also matches a negative pattern defined later in the file, the file will not be included. | `hello.md`

_Does not match_

`README.md`

`docs/hello.md` | | `'*.md'`

`'!README.md'`

`README*` | Patterns are checked sequentially. A pattern that negates a previous pattern will re-include file paths. | `hello.md`

`README.md`

`README.doc` | + + diff --git a/content/enterprise-onboarding/getting-started-with-your-enterprise/adding-users-to-your-enterprise.md b/content/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/add-users.md similarity index 71% rename from content/enterprise-onboarding/getting-started-with-your-enterprise/adding-users-to-your-enterprise.md rename to content/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/add-users.md index ff975cccfe8e..b8543063daa4 100644 --- a/content/enterprise-onboarding/getting-started-with-your-enterprise/adding-users-to-your-enterprise.md +++ b/content/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/add-users.md @@ -1,14 +1,20 @@ --- title: Adding users to your enterprise shortTitle: Add users -intro: 'Add users to your enterprise and control access to your organization''s resources.' +intro: You can add people directly to your enterprise. +permissions: Enterprise owners versions: ghec: '*' +contentType: other +category: + - Manage accounts and repositories +docsTeamMetrics: + - enterprise-onboarding redirect_from: + - /admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/invite-users-directly - /enterprise-onboarding/getting-started-with-your-enterprise/securing-enterprise-resources-with-single-sign-on - /enterprise-onboarding/getting-started-with-your-enterprise/securing-your-enterprise-with-managed-users -docsTeamMetrics: - - enterprise-onboarding + - /enterprise-onboarding/getting-started-with-your-enterprise/adding-users-to-your-enterprise --- The method of adding users to your enterprise and controlling authentication varies depending on the enterprise type that you chose. @@ -17,9 +23,14 @@ The method of adding users to your enterprise and controlling authentication var If you chose an enterprise with personal accounts, you will invite users to your enterprise with their existing {% data variables.product.github %} account. -{% data reusables.enterprise-onboarding.inviting-users-to-your-enterprise %} +{% data reusables.enterprise-accounts.access-enterprise %} +{% data reusables.enterprise-accounts.people-tab %} +1. On the "Members" page, click **Invite member**. +1. Search for the users you want to invite, then click **Invite**. -Later in this onboarding journey, you will add users to teams to grant access to organizations and delegate administrative roles. +After you invite someone to join the enterprise account, they must accept the emailed invitation before they can access the enterprise account. Pending invitations will expire after 7 days. + +Users will join the enterprise as unaffiliated users. You can then add users to organizations or enterprise teams and assign {% data variables.product.prodname_copilot_short %} licenses to them. For more information about unaffiliated users, see [AUTOTITLE](/admin/managing-accounts-and-repositories/managing-roles-in-your-enterprise/abilities-of-roles#unaffiliated-users). ### Enabling single sign-on for personal accounts @@ -48,7 +59,3 @@ To use {% data variables.product.prodname_emus %}, you will: * Provision users to your enterprise To get started, see [AUTOTITLE](/enterprise-cloud@latest/admin/managing-iam/understanding-iam-for-enterprises/getting-started-with-enterprise-managed-users). - -## Next steps - -Learn about how billing will work when your trial ends. See [AUTOTITLE](/billing/concepts/enterprise-billing/billing-for-enterprises). diff --git a/content/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/index.md b/content/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/index.md index 71915a2e87fd..f1dbec910cd1 100644 --- a/content/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/index.md +++ b/content/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/index.md @@ -17,7 +17,7 @@ versions: children: - /best-practices-for-user-security - /create-enterprise-teams - - /invite-users-directly + - /add-users - /inviting-people-to-manage-your-enterprise - /managing-invitations-to-organizations-within-your-enterprise - /about-reserved-usernames-for-github-enterprise-server diff --git a/content/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/invite-users-directly.md b/content/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/invite-users-directly.md deleted file mode 100644 index 1e2108da6e47..000000000000 --- a/content/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/invite-users-directly.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: Inviting users to your enterprise directly -shortTitle: Invite users directly -intro: You can invite people directly to your enterprise as unaffiliated users. -permissions: Enterprise owners -versions: - ghec: '*' -product: Enterprises that use **personal accounts** on {% data variables.product.prodname_dotcom_the_website %}. -contentType: how-tos -category: - - Manage accounts and repositories ---- - -You can invite people directly to your enterprise as **unaffiliated users**. You can then add these users to organizations or enterprise teams and assign {% data variables.product.prodname_copilot_short %} licenses to them. For more information about unaffiliated users, see [AUTOTITLE](/admin/managing-accounts-and-repositories/managing-roles-in-your-enterprise/abilities-of-roles#unaffiliated-users). - -## Inviting users - ->[!NOTE] These steps apply to enterprises that use personal accounts. If you use {% data variables.product.prodname_emus %}, you must add users to your enterprise from your identity provider using SCIM. - -{% data reusables.enterprise-onboarding.inviting-users-to-your-enterprise %} - -## Next steps - -* To add users to organizations, see [AUTOTITLE](/organizations/managing-membership-in-your-organization/inviting-users-to-join-your-organization). -* To add users to an enterprise team, see [AUTOTITLE](/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/create-enterprise-teams). -* To assign {% data variables.product.prodname_copilot_short %} licenses, see [AUTOTITLE](/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-access/grant-access). diff --git a/content/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/managing-support-entitlements-for-your-enterprise.md b/content/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/managing-support-entitlements-for-your-enterprise.md index ab4d09d3289f..555194ea67d0 100644 --- a/content/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/managing-support-entitlements-for-your-enterprise.md +++ b/content/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/managing-support-entitlements-for-your-enterprise.md @@ -25,6 +25,8 @@ Enterprise owners and billing managers automatically have a support entitlement. > * If the user does not have a support entitlement, their ticket will still be addressed by our Enterprise Support team, but without Premium Support features such as priority selection and guaranteed Premium SLAs. > > If a user is unsure of their entitlement status, they can contact their organization's Enterprise Support administrator. +> +Support entitlements do not provide a user with rights above those granted by the role of their account in the enterprise. Additional approval from an enterprise owner will still be required where the user's enterprise role does not permit the sharing of information in a support ticket. ## Adding a support entitlement to an enterprise member diff --git a/content/authentication/keeping-your-account-and-data-secure/preventing-unauthorized-access.md b/content/authentication/keeping-your-account-and-data-secure/preventing-unauthorized-access.md index 5642a855d6f5..b14bc45c6ef7 100644 --- a/content/authentication/keeping-your-account-and-data-secure/preventing-unauthorized-access.md +++ b/content/authentication/keeping-your-account-and-data-secure/preventing-unauthorized-access.md @@ -29,3 +29,20 @@ After changing your password, you should perform these actions to make sure that * Make sure that no new deploy keys were created. This could enable outside servers access to your projects. For more information, see [AUTOTITLE](/authentication/connecting-to-github-with-ssh/managing-deploy-keys#deploy-keys). * Review recent commits made to your repositories. * Review the list of collaborators for each repository. + +{% ifversion fpt or ghec %} +## Troubleshooting + +### Account is restricted after suspected compromise + +If {% data variables.product.github %} detects suspicious activity, your personal account may be temporarily restricted while you can still sign in. During this time, your profile URL, contribution graph, search visibility, or sensitive account actions may be unavailable. Alternatively, we may suspend the account for security reasons. If you’re unable to access your account at all, please contact {% data variables.contact.github_support %}. + +If you see restrictions on your account, complete the following steps to secure your account: + +1. Change your {% data variables.product.github %} password. For more information, see [AUTOTITLE](/authentication/keeping-your-account-and-data-secure/updating-your-github-access-credentials#changing-an-existing-password). +1. Review your security settings and remove unfamiliar apps, keys, and other credentials. +1. Secure the email account associated with {% data variables.product.github %} and make sure you can access it. +1. Check your inbox (and spam folder) for security emails from {% data variables.product.github %} and follow any instructions. + +If restrictions remain after you secure your account, contact {% data variables.contact.github_support %}. +{% endif %} diff --git a/content/code-security/concepts/code-scanning/repository-properties.md b/content/code-security/concepts/code-scanning/repository-properties.md index 4fb3488b2c1e..cdc069f161b9 100644 --- a/content/code-security/concepts/code-scanning/repository-properties.md +++ b/content/code-security/concepts/code-scanning/repository-properties.md @@ -35,9 +35,6 @@ The following is an overview of repository properties you can set up which affec | `github-codeql-extra-queries` | Text | | `github-codeql-disable-overlay` | True/false | | `github-codeql-file-coverage-on-prs` | True/false | -| {% ifversion codeql-config-property %} | -| `github-codeql-tools` | Text | -| {% endif %} | > [!NOTE] > The repository properties which are supported depend on the version of the [github/codeql-action](https://github.com/github/codeql-action/) that is used by your {% data variables.product.prodname_code_scanning %} analyses. For {% data variables.product.prodname_code_scanning %} advanced setup, check that your workflow is referencing the latest major version. {% data variables.product.prodname_code_scanning_caps %} default setup automatically uses the latest version.{% ifversion ghes %} If the server on which you are running {% data variables.product.prodname_ghe_server %} is not connected to the internet, you may need to use the {% data variables.product.prodname_codeql %} action sync tool. See [AUTOTITLE](/code-security/how-tos/secure-at-scale/configure-enterprise-security/configure-specific-tools/configuring-code-scanning-for-your-appliance#configuring-codeql-analysis-on-a-server-without-internet-access).{% endif %} @@ -59,14 +56,6 @@ A value specified for the `github-codeql-config-file` property will apply to bot The `github-codeql-extra-queries` property allows you to configure additional queries that should be run. This is useful to add queries to all relevant analyses in your organization without needing to modify individual workflows or switch to an advanced setup. This accepts the same values as the `queries` input of the [github/codeql-action](https://github.com/github/codeql-action/). See [AUTOTITLE](/code-security/reference/code-scanning/workflow-configuration-options). -{% ifversion codeql-config-property %} - -By default, {% data variables.product.prodname_code_scanning %} analyses use the latest released version of CodeQL. It is not generally recommended to change this, unless you are running into a specific issue that is resolved by switching to a different version. If you do need to change this, the `github-codeql-tools` property allows you to specify a different version. - -If an advanced setup workflow specifies an explicit input for the `tools` parameter of the `codeql-action/init` action, then that input will take precedence over the value configured in the repository property. This allows advanced workflows to use different configurations than those applied to default setup workflows, if desired. To enforce the value of the repository property to advanced setup workflows even if they have an explicit `tools` input, add a `!` prefix to the value of the repository property. For example, `!nightly` enforces that all workflows use the latest `nightly` release. - -{% endif %} - ### Enabling or disabling features You can disable improved incremental analysis by setting the `github-codeql-disable-overlay` property to `true`. This may be useful if improved incremental analysis is failing because of increased hardware requirements. diff --git a/content/code-security/how-tos/secure-at-scale/configure-organization-security/manage-usage-and-access/giving-org-access-private-registries.md b/content/code-security/how-tos/secure-at-scale/configure-organization-security/manage-usage-and-access/giving-org-access-private-registries.md index 53a28a0d85d0..01cfb5fb95f1 100644 --- a/content/code-security/how-tos/secure-at-scale/configure-organization-security/manage-usage-and-access/giving-org-access-private-registries.md +++ b/content/code-security/how-tos/secure-at-scale/configure-organization-security/manage-usage-and-access/giving-org-access-private-registries.md @@ -14,7 +14,7 @@ category: ## About the importance of providing access to private registries -When code in a repository has dependencies that are stored in a private registry, some security features need access to the registry to enable them to work effectively. Without access to all the dependencies of a repository, the effectiveness of {% ifversion code-quality %}{% data variables.product.prodname_code_quality_short %} ({% data variables.release-phases.public_preview %}), {% endif %}{% data variables.product.prodname_code_scanning %} default setup and {% data variables.product.prodname_dependabot %} are limited. +When code in a repository has dependencies that are stored in a private registry, some security features need access to the registry to enable them to work effectively. Without access to all the dependencies of a repository, the effectiveness of {% ifversion code-quality %}{% data variables.product.prodname_code_quality_short %}, {% endif %}{% data variables.product.prodname_code_scanning %} default setup and {% data variables.product.prodname_dependabot %} are limited. ## {% data variables.product.prodname_code_scanning_caps %} default setup access to private registries @@ -114,8 +114,6 @@ For more information about how OIDC works, see [AUTOTITLE](/actions/concepts/sec ## {% data variables.product.prodname_code_quality_short %} access to private registries -{% data reusables.code-quality.code-quality-preview-note %} - {% data variables.product.prodname_code_quality %} can use any of the organization-level private registries that are available when it is enabled for a repository. If you add new registries to the organization, then you need to disable and re-enable {% data variables.product.prodname_code_quality_short %} to ensure that the analysis detects and uses the new registries. diff --git a/content/code-security/tutorials/secure-your-dependencies/automate-dependabot-with-actions.md b/content/code-security/tutorials/secure-your-dependencies/automate-dependabot-with-actions.md index 8fc2ad060ae7..c73f0ab07be4 100644 --- a/content/code-security/tutorials/secure-your-dependencies/automate-dependabot-with-actions.md +++ b/content/code-security/tutorials/secure-your-dependencies/automate-dependabot-with-actions.md @@ -39,6 +39,13 @@ You can use {% data variables.product.prodname_actions %} to perform automated t {% data reusables.dependabot.working-with-actions-considerations %} For more information, see [AUTOTITLE](/code-security/reference/supply-chain-security/troubleshoot-dependabot/dependabot-on-actions). +{% ifversion copilot %} + +> [!NOTE] +> You can also use {% data variables.copilot.agentic_workflows_short %} for dependency analysis, update summaries, and remediation recommendations, while keeping security enforcement and merge gating in deterministic {% data variables.product.prodname_actions %} workflows. For more information, see [AUTOTITLE](/copilot/how-tos/github-agentic-workflows/creating-github-agentic-workflows). + +{% endif %} + Here are several common scenarios for pull requests that can be automated using {% data variables.product.prodname_actions %}. ## Fetching metadata about a pull request @@ -147,7 +154,7 @@ jobs: If you want to allow maintainers to mark certain pull requests for automerge, you can use {% data variables.product.prodname_dotcom %}'s automerge functionality. This enables the pull request to be merged when any tests and approvals required by the branch protection rules are successfully met. -For more information, see [AUTOTITLE](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request) and [AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule). +For more information, see [AUTOTITLE](/pull-requests/how-tos/merge-and-close-pull-requests/automatically-merging-a-pull-request) and [AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule). You can instead use {% data variables.product.prodname_actions %} and the {% data variables.product.prodname_cli %}. Here is an example that automerges all patch updates to `my-dependency`: @@ -209,3 +216,4 @@ If your workflow run fails, check the following: For information on writing and debugging {% data variables.product.prodname_actions %}, see [AUTOTITLE](/actions/how-tos/write-workflows). For more tips to help resolve issues with workflows, see [AUTOTITLE](/code-security/reference/supply-chain-security/troubleshoot-dependabot/dependabot-on-actions). + diff --git a/content/copilot/get-started/enterprise-ai-governance.md b/content/copilot/get-started/enterprise-ai-governance.md index c7f9c7ac9a31..7c195840247b 100644 --- a/content/copilot/get-started/enterprise-ai-governance.md +++ b/content/copilot/get-started/enterprise-ai-governance.md @@ -47,6 +47,6 @@ journeyTracks: title: 'Adopting new features' description: 'Expand your capabilities by assessing and rolling out any new feature or model.' guides: - - href: '/copilot/concepts/preparing-for-new-features-and-models' + - href: '/copilot/concepts/learning-about-new-features-and-models' - href: '/copilot/tutorials/roll-out-at-scale/govern-at-scale/pilot-a-feature-or-model' --- diff --git a/content/copilot/how-tos/copilot-on-github/set-up-copilot/enable-copilot/set-up-for-students.md b/content/copilot/how-tos/copilot-on-github/set-up-copilot/enable-copilot/set-up-for-students.md index c00e0de29550..3713a7e17c93 100644 --- a/content/copilot/how-tos/copilot-on-github/set-up-copilot/enable-copilot/set-up-for-students.md +++ b/content/copilot/how-tos/copilot-on-github/set-up-copilot/enable-copilot/set-up-for-students.md @@ -27,3 +27,16 @@ To become a verified student, see [AUTOTITLE](/free-pro-team@latest/education/ab If you are not yet a verified student, click **Start an application** and complete the verification process. 1. Under "Free {% data variables.product.github %} developer resources for students and teachers", click **Learn more**. 1. Follow the prompts to activate {% data variables.copilot.copilot_student_short %}, configuring the {% data variables.product.prodname_copilot_short %} use policies to meet your needs. + +## Troubleshooting + +### Account shows {% data variables.copilot.copilot_free_short %}, a trial, or a paid checkout page after your {% data variables.product.prodname_education %} verification is approved + +Approval and {% data variables.product.prodname_copilot_short %} activation are separate steps. The student benefit can take several days to finish applying after verification. + +While you wait, you can try activating your included plan using one of the following steps: + +* Navigate to your [{% data variables.product.prodname_copilot_short %} settings](https://github.com/settings/copilot) and follow the prompts. +* Go directly to https://github.com/github-copilot/free_signup. + +If only paid options appear, do not complete a purchase. Wait a few days and try again. If the problem continues after several days, contact {% data variables.contact.contact_support_page %}. diff --git a/content/copilot/reference/enterprise-administrators/enterprise-managed-settings.md b/content/copilot/reference/enterprise-administrators/enterprise-managed-settings.md index d5b6c816cdcd..792d2dc9f08f 100644 --- a/content/copilot/reference/enterprise-administrators/enterprise-managed-settings.md +++ b/content/copilot/reference/enterprise-administrators/enterprise-managed-settings.md @@ -30,7 +30,7 @@ When multiple settings sources are present, settings earlier in this list take p | Key | Purpose | {% data variables.copilot.copilot_cli_short %} | {% data variables.product.prodname_vscode_shortname %} | {% data variables.copilot.github_copilot_app %} | {% data variables.copilot.copilot_cloud_agent %} | | --- | --- | --- | --- | --- | --- | | `permissions.disableBypassPermissionsMode` | Disables bypass or YOLO-style allow-all behavior | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "x" aria-label="Not supported" %} | -| `permissions.model` | Sets auto model selection as the default for new conversations | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "x" aria-label="Not supported" %} | +| `permissions.model` | Sets auto model selection as the default for new conversations | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | | `enabledPlugins` | Enables or disables specific plugins by key | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | | `extraKnownMarketplaces` | Adds plugin marketplaces that users can access | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | | `strictKnownMarketplaces` | Restricts plugin installation to explicitly listed marketplaces | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | diff --git a/content/enterprise-onboarding/getting-started-with-your-enterprise/index.md b/content/enterprise-onboarding/getting-started-with-your-enterprise/index.md index 36e2282f296a..79837c1a6012 100644 --- a/content/enterprise-onboarding/getting-started-with-your-enterprise/index.md +++ b/content/enterprise-onboarding/getting-started-with-your-enterprise/index.md @@ -6,7 +6,6 @@ versions: shortTitle: Get started children: - /setting-up-a-trial-of-github-enterprise - - /adding-users-to-your-enterprise - /about-migrating-to-github-enterprise-cloud docsTeamMetrics: - enterprise-onboarding diff --git a/content/enterprise-onboarding/index.md b/content/enterprise-onboarding/index.md index 87de13e22370..bbd361bbad1b 100644 --- a/content/enterprise-onboarding/index.md +++ b/content/enterprise-onboarding/index.md @@ -9,7 +9,7 @@ journeyTracks: guides: - href: '/admin/concepts/enterprise-fundamentals/choose-an-enterprise-type' - href: '/enterprise-onboarding/getting-started-with-your-enterprise/setting-up-a-trial-of-github-enterprise' - - href: '/enterprise-onboarding/getting-started-with-your-enterprise/adding-users-to-your-enterprise' + - href: '/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/add-users' - href: '/billing/concepts/enterprise-billing/billing-for-enterprises' - href: '/enterprise-onboarding/getting-started-with-your-enterprise/about-migrating-to-github-enterprise-cloud' - id: 'setting_up_organizations_and_teams' diff --git a/content/issues/planning-and-tracking-with-projects/automating-your-project/automating-projects-using-actions.md b/content/issues/planning-and-tracking-with-projects/automating-your-project/automating-projects-using-actions.md index 4d2d923a4818..c9da0d99ee9d 100644 --- a/content/issues/planning-and-tracking-with-projects/automating-your-project/automating-projects-using-actions.md +++ b/content/issues/planning-and-tracking-with-projects/automating-your-project/automating-projects-using-actions.md @@ -30,9 +30,14 @@ For more information about other changes you can make to your project through th You may also want to use the **actions/add-to-project** workflow, which is maintained by {% data variables.product.company_short %} and will add the current issue or pull request to the project specified. For more information, see the [actions/add-to-project](https://github.com/actions/add-to-project) repository and README. +{% ifversion copilot %} + +For project management tasks that require understanding repository context—such as triaging new issues, summarizing backlogs, classifying issues by type or priority, and recommending field values—{% data variables.copilot.agentic_workflows_short %} are a better fit than traditional {% data variables.product.prodname_actions %} workflows. Unlike fixed workflow steps, {% data variables.copilot.agentic_workflows_short %} let you describe what you want in natural language, and an AI coding agent handles the reasoning and decision-making. For more information, see [AUTOTITLE](/copilot/how-tos/github-agentic-workflows/creating-github-agentic-workflows). + +{% endif %} + > [!NOTE] > `GITHUB_TOKEN` is scoped to the repository level and cannot access {% data variables.projects.projects_v2 %}. To access {% data variables.projects.projects_v2 %} you can either create a {% data variables.product.prodname_github_app %} (recommended for organization projects) or a {% data variables.product.pat_generic %} (recommended for user projects). Workflow examples for both approaches are shown below. - ## Example workflow authenticating with a {% data variables.product.prodname_github_app %} For more information about authenticating in a {% data variables.product.prodname_actions %} workflow with a {% data variables.product.prodname_github_app %}, see [AUTOTITLE](/apps/creating-github-apps/authenticating-with-a-github-app/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow). @@ -318,3 +323,5 @@ jobs: }' -f project=$PROJECT_ID -f item=$ITEM_ID -f status_field=$STATUS_FIELD_ID -f status_value={% raw %}${{ env.TODO_OPTION_ID }}{% endraw %} -f date_field=$DATE_FIELD_ID -f date_value=$DATE --silent ``` + + diff --git a/content/pull-requests/get-started/about-stacked-prs.md b/content/pull-requests/get-started/about-stacked-prs.md index 704a9cf79c28..0404968f4c36 100644 --- a/content/pull-requests/get-started/about-stacked-prs.md +++ b/content/pull-requests/get-started/about-stacked-prs.md @@ -113,7 +113,7 @@ You can merge your entire stack, a single pull request, or a portion of the stac Stacks support merge commit, squash, and rebase merge methods, and they are merge-queue aware. The resulting commit history is the same as merging each pull request individually, starting from the bottom. > [!NOTE] -> If you merge via the API and want to use stacked pull requests, you'll need to update to use the new merge API for stacks. See [AUTOTITLE](/rest/pulls/pulls?apiVersion=2026-03-10#merge-a-pull-request-asynchronously). +> If you merge via the API and want to use stacked pull requests, you'll need to use the asynchronous merge API for stacks. See [AUTOTITLE](/rest/pulls/pulls?apiVersion=2026-03-10#merge-a-pull-request-asynchronously). ## Next steps diff --git a/content/pull-requests/how-tos/merge-and-close-pull-requests/merging-stacked-pull-requests.md b/content/pull-requests/how-tos/merge-and-close-pull-requests/merging-stacked-pull-requests.md index 85b006b9dd4c..b78c3a68d5c1 100644 --- a/content/pull-requests/how-tos/merge-and-close-pull-requests/merging-stacked-pull-requests.md +++ b/content/pull-requests/how-tos/merge-and-close-pull-requests/merging-stacked-pull-requests.md @@ -27,7 +27,7 @@ The merge box for a stacked pull request shows the status of the entire stack, n If the stack is not linear, for example, after changes were pushed to a lower branch or after the trunk moved ahead, a **Rebase stack** button will appear in the merge box and you'll need to rebase the stack before you can merge. > [!NOTE] -> * If you merge via the API and want to use stacked pull requests, you'll need to update your code to use the new merge API for stacks. See [AUTOTITLE](/rest/pulls/pulls?apiVersion=2026-03-10#merge-a-pull-request-asynchronously). +> * If you merge via the API and want to use stacked pull requests, you'll need use the asynchronous merge API for stacks. See [AUTOTITLE](/rest/pulls/pulls?apiVersion=2026-03-10#merge-a-pull-request-asynchronously). > * Auto-merge is not supported for stacked pull requests. ## Merging using a merge queue diff --git a/content/pull-requests/how-tos/stacked-pull-requests/index.md b/content/pull-requests/how-tos/stacked-pull-requests/index.md index 852d55e00f80..b9b0b49e92c2 100644 --- a/content/pull-requests/how-tos/stacked-pull-requests/index.md +++ b/content/pull-requests/how-tos/stacked-pull-requests/index.md @@ -23,7 +23,7 @@ children: - /content/pull-requests/tutorials/stack-code-changes-in-pull-requests - /content/pull-requests/reference/stacked-pull-requests - /content/pull-requests/reference/stacked-prs-cli-commands - - /content/pull-requests/reference/stacked-pull-requests-rest-and-graphql-apis + - /content/pull-requests/reference/stacked-pull-requests-apis-and-webhooks - /content/rest/pulls/pulls - /content/graphql/reference/pulls - /content/webhooks/webhook-events-and-payloads diff --git a/content/pull-requests/index.md b/content/pull-requests/index.md index 352894c990a7..cb6410714502 100644 --- a/content/pull-requests/index.md +++ b/content/pull-requests/index.md @@ -9,20 +9,19 @@ redirect_from: - /categories/collaborating-on-projects-using-issues-and-pull-requests - /categories/collaborating-with-issues-and-pull-requests - /github/collaborating-with-pull-requests -intro: 'Discover how to create, review, and merge pull requests, resolve merge conflicts, and collaborate effectively on {% data variables.product.github %} projects.' +intro: 'Discover how to create, review, and merge pull requests, resolve merge conflicts, and work with forks.' introLinks: overview: /pull-requests/get-started/about-pull-requests layout: discovery-landing carousels: recommended: - - /pull-requests/reference/pull-requests + - /pull-requests/get-started/about-pull-requests - /pull-requests/reference/branches - /pull-requests/how-tos/create-pull-requests/creating-a-pull-request - /pull-requests/how-tos/review-pull-requests/reviewing-proposed-changes-in-a-pull-request - /pull-requests/how-tos/merge-and-close-pull-requests/merging-a-pull-request - /pull-requests/how-tos/merge-and-close-pull-requests/resolving-a-merge-conflict-on-github - /pull-requests/how-tos/work-with-forks/fork-a-repo - - /pull-requests/how-tos/work-with-forks/syncing-a-fork - /pull-requests/reference/commits includedCategories: - Create pull requests diff --git a/content/pull-requests/reference/index.md b/content/pull-requests/reference/index.md index e9d0b62e2c96..c3ed2efce1a4 100644 --- a/content/pull-requests/reference/index.md +++ b/content/pull-requests/reference/index.md @@ -10,7 +10,7 @@ children: - /pull-requests - /stacked-pull-requests - /stacked-prs-cli-commands - - /stacked-pull-requests-rest-and-graphql-apis + - /stacked-pull-requests-apis-and-webhooks - /branches - /forks - /commits diff --git a/content/pull-requests/reference/stacked-pull-requests-rest-and-graphql-apis.md b/content/pull-requests/reference/stacked-pull-requests-apis-and-webhooks.md similarity index 50% rename from content/pull-requests/reference/stacked-pull-requests-rest-and-graphql-apis.md rename to content/pull-requests/reference/stacked-pull-requests-apis-and-webhooks.md index 3e1d0812e2ba..18a249a5b98b 100644 --- a/content/pull-requests/reference/stacked-pull-requests-rest-and-graphql-apis.md +++ b/content/pull-requests/reference/stacked-pull-requests-apis-and-webhooks.md @@ -1,13 +1,16 @@ --- -title: Stacked pull requests in the REST and GraphQL APIs -shortTitle: Stacked PRs APIs -intro: Read and manage stacked pull requests programmatically with the {% data variables.product.github %} REST and GraphQL APIs. +title: Stacked pull requests APIs and webhooks +shortTitle: Stacked PRs APIs and webhooks +intro: Read and manage stacked pull requests programmatically with the {% data variables.product.github %} REST and GraphQL APIs, and webhooks. allowTitleToDifferFromFilename: true +redirect_from: + - /pull-requests/reference/stacked-pull-requests-rest-and-graphql-apis versions: feature: pr-stacks contentType: reference category: - Create pull requests + - Merge and close pull requests --- {% data reusables.public-preview.public-preview %} @@ -23,11 +26,21 @@ The REST API exposes stacked pull requests in two ways: * **The `stack` object on pull request resources.** When a pull request belongs to a stack, its REST resource includes a `stack` object. This lets you read the pull request's stack membership, including the stack's number and size and the pull request's position and base, directly from the pull request. * **The Stacks API.** A dedicated set of endpoints to list, read, create, extend, and dissolve stacks. This is the surface for creating and modifying stacks. -> [!NOTE] -> If you merge via the API and want to use stacked pull requests, you'll need to update your code to use the new merge API for stacks. See [AUTOTITLE](/rest/pulls/pulls?apiVersion=2026-03-10#merge-a-pull-request-asynchronously). - For endpoints, parameters, and schemas, see [AUTOTITLE](/rest/pulls/pulls). +> [!IMPORTANT] +> If you merge via the API and want to use stacked pull requests, you must use the new asynchronous merge API. + +### Merge API + +When you merge a stacked pull request via the API, you must use the asynchronous merge endpoint. + +A stack cannot be merged with the legacy synchronous merge endpoints or mutations. When you merge a stacked pull request, every pull request in the stack up to and including the one you request is merged or queued to merge into the base branch. Merging a pull request stack may involve several pull requests that may take a few minutes to merge. Because of this, the merge runs in the background when you submit a merge request and then you can poll for the result. + +Only the basic pull request state is checked when you submit an open PR. Branch protection and repository rules are evaluated later, when the merge actually runs, and a rule failure is reported as a failed result while polling. A stack merge request is atomic, meaning either the whole group of pull requests merges, or is added to the merge queue, or none of it is. + +For details, see [AUTOTITLE](/rest/pulls/pulls?apiVersion=2026-03-10#merge-a-pull-request-asynchronously). + ## GraphQL API The GraphQL API exposes a pull request's stack membership through read-only `stack` and `stackEntry` fields on the `PullRequest` type. Use these fields to query the stack a pull request belongs to and its position within it. @@ -36,6 +49,14 @@ The GraphQL API is read-only for stacks; there are no stack mutations. To create For fields, objects, and schemas, see [AUTOTITLE](/graphql/reference/pulls#object-pullrequeststack). +## Webhooks + +When a pull request belongs to a stack, {% data variables.product.github %} adds a `stack` property to the `pull_request` object in webhook event payloads. This lets apps and integrations inspect the stack's target branch, not just the direct parent branch of the pull request. + +The `stack` object is included in the `pull_request` webhook payload for pull request lifecycle events that happen while the pull request is part of a stack. + +See [AUTOTITLE](/webhooks/webhook-events-and-payloads?actionType=stacked#pull_request). + ## Further reading * [AUTOTITLE](/pull-requests/reference/stacked-prs-cli-commands) diff --git a/content/pull-requests/tutorials/roll-out-stacked-prs.md b/content/pull-requests/tutorials/roll-out-stacked-prs.md index 0896e8aba727..7e331e99aa54 100644 --- a/content/pull-requests/tutorials/roll-out-stacked-prs.md +++ b/content/pull-requests/tutorials/roll-out-stacked-prs.md @@ -1,7 +1,7 @@ --- title: Roll out stacked pull requests to your organization shortTitle: Roll out stacked PRs -intro: 'Plan and roll out stacked pull requests to your organization, so your teams can ship large changes as small, reviewable layers without compromising your existing rules and checks.' +intro: 'Stacked pull requests help your organization maintain review quality as teams deliver large changes in small, reviewable layers, while keeping required reviews and status checks in place.' versions: feature: pr-stacks contentType: tutorials @@ -13,68 +13,65 @@ category: > [!NOTE] > Stacked pull requests are in {% data variables.release-phases.public_preview %} and subject to change. -Stacked pull requests let developers break large changes into a chain of small, focused pull requests that build on each other, making each layer easier to review, merge, and ship. Stacked pull requests give developers the flexibility to finish one piece of work and move straight to the next without waiting for reviews to land. This matters most when work naturally depends on what came before it, which is common when a team is working on a big release and every change builds on the last. +Stacked pull requests let developers break large changes into a chain of small, focused pull requests that build on each other. This approach can help your organization maintain review quality as developers produce more code, including with {% data variables.product.prodname_copilot_short %} and other coding agents. -This tutorial walks you through preparing your organization for stacked pull requests: reviewing rollout considerations, understanding how your branch protection rules and CI work with stacks, and getting your teams started. For a fundamental understanding of stacked pull requests, see [AUTOTITLE](/pull-requests/get-started/about-stacked-prs). +Stacked pull requests require **no setup or enablement**. If your team already uses pull requests, they can create a stack today. The steps below help you prepare your existing controls and support a smooth rollout, not turn a feature on. -## Prerequisites +This tutorial helps you decide whether stacked pull requests fit your organization, make sure the foundations are in place, pilot the workflow, support adoption, and update programmatic tooling. For a fundamental understanding of stacked pull requests, see [AUTOTITLE](/pull-requests/get-started/about-stacked-prs). -If your team is already using pull requests, you're set up to use stacked pull requests. Everything else in this tutorial is optional, but assumes your organization has: +## 1. Decide if stacked pull requests are the right fit -* {% data variables.product.prodname_cli %}, with the `gh-stack` extension installed. The CLI extension is the most comprehensive way to create and manage stacks. -* Branch protection rules configured for your default branch. -* {% data variables.product.prodname_actions %} workflows that run on pull requests targeting your default branch. +Use this quick self-check before investing in a rollout: -{% data variables.product.prodname_copilot_short %} isn't required to use stacked pull requests, but is encouraged for teams that want to stack AI-generated changes. Stacked pull requests also work with other AI coding agents, such as Claude Code and Codex, using the provided agent skill. See [AUTOTITLE](/copilot/tutorials/stack-ai-generated-code-in-pull-requests). +* Do your teams produce a high volume of code, either themselves or with {% data variables.product.prodname_copilot_short %} or other coding agents? +* Do your teams work on large features, especially inside monorepos, that are difficult to split into independent pull requests? -## 1. Review rollout considerations +If either describes your teams, stacked pull requests can help them submit dependent changes in smaller units without waiting for each pull request to merge before starting the next one, as long as their work fits one constraint: every pull request in a stack must be in the same repository, following a single, linear chain of branches. Stacks can't include forks or branching structures, so teams that rely heavily on forks for contributions should keep those contributions outside stacks for now. -Before you introduce stacked pull requests to your teams, review the following considerations so everyone knows what to expect. +## 2. Make sure the foundations are in place -### Stacks must be linear, and can't include forks +Each pull request in a stack is evaluated against the **base of the stack** (typically `main`), rather than the branch it directly targets. Your existing branch protection rules or rulesets and CI workflows apply automatically: -Every pull request in a stack must be part of the same repository and build on a single, linear chain of branches. Stacks with branching structures, or pull requests from forks, aren't supported. If your teams rely on forks for contributions, plan to keep those contributions outside of stacks for now. +* Required reviews, required status checks, and CODEOWNERS are all enforced against the stack's base branch for every pull request in the stack. +* A {% data variables.product.prodname_actions %} workflow that triggers on `pull_request` events targeting the default branch of a repository runs for **every** pull request in the stack, so your existing CI configuration doesn't need to change. +* Stack metadata is available in workflow expressions via `github.event.pull_request.stack`, if you want to customize workflow behavior specifically for stacked pull requests. Since a workflow runs once per pull request in a stack, teams can use this metadata to limit expensive jobs and reduce CI usage. For details, see [AUTOTITLE](/pull-requests/how-tos/merge-and-close-pull-requests/optimizing-ci-for-stacked-pull-requests). -### Reordering a stack requires {% data variables.product.prodname_cli %} +One optional addition worth considering: if developers need to reorder pull requests after creating a stack without dissolving it, adopt the `gh stack` extension for {% data variables.product.prodname_cli %}. In-place reordering requires `gh stack modify`; on the {% data variables.product.github %} website, developers must unstack the pull requests and recreate the stack in the desired order. -If your team needs to reorder the pull requests in a stack, they will need to use `gh stack modify` in the `gh stack` {% data variables.product.prodname_cli %} extension. There's no way to reorder a stack from the {% data variables.product.github %} website. Teams who don't use the CLI locally should plan their stack order carefully upfront, or install the extension for this task. +A stack also closes automatically once every pull request in it has merged. If a team adds new branches on top of a merged stack and runs `gh stack submit`, the CLI starts a new stack with the same base branch. It doesn't extend the original. Teams who want to keep working across a set of changes should plan to keep the stack open until all the work is complete. -### A completed stack can't be extended +For the full list of rules and requirements, see [AUTOTITLE](/pull-requests/reference/stacked-pull-requests). -Once every pull request in a stack has merged, that stack is closed. If a team adds new branches on top and runs `gh stack submit`, the CLI starts a new stack with the same base branch. Teams who want to continue working on a stack should plan to keep the stack open until all work is complete. +## 3. Pilot with a small group -## 2. Understand how branch protection rules and CI work with stacks +Choose a small group of developers who produce a high volume of code, either themselves or through {% data variables.product.prodname_copilot_short %} or other coding agents. Ask the group to use a real, representative feature for the pilot instead of a disposable example. -Stacked pull requests are designed to enforce your existing rules the same way as any other pull request, but it's worth understanding how, since every pull request in a stack is evaluated a bit differently than you might expect. +To create their first stack, direct people to [AUTOTITLE](/pull-requests/get-started/stacked-prs-quickstart). After the pilot, gather feedback from developers and reviewers on: -Every pull request in a stack, not just the bottom one, is evaluated against the **base of the stack** (typically `main`), rather than against the branch it directly targets. That means: +* How stack planning fit into their existing workflow, and whether developers need in-place reordering, which requires the `gh stack` extension +* Whether review flow felt different now that every pull request in the stack carries its own required reviews and status checks +* Any support or documentation gaps they ran into -* Required reviews, required status checks, and CODEOWNERS are all enforced against the stack's base branch for every pull request in the stack. -* A {% data variables.product.prodname_actions %} workflow that triggers on `pull_request` events targeting `main` runs for **every** pull request in the stack, so your existing CI configuration doesn't need to change. -* Stack metadata is available in workflow expressions via `github.event.pull_request.stack`, if you want to customize workflow behavior specifically for stacked pull requests. Since a workflow runs once per pull request in a stack, teams can use this metadata to skip expensive jobs on redundant runs and reduce CI usage. For details, see [AUTOTITLE](/pull-requests/how-tos/merge-and-close-pull-requests/optimizing-ci-for-stacked-pull-requests). +## 4. Roll out and support adoption -Optionally, you can see this in action by opening a small test stack against a repository with your standard rulesets and required checks in place, and confirming that: +After the pilot, share day-to-day guidance on creating, reviewing, managing, and merging stacks with teams: [AUTOTITLE](/pull-requests/how-tos/stacked-pull-requests). -1. Reviews and status checks are required on every pull request in the stack, not just the bottom one. -1. Your CI workflows run on every pull request in the stack. -1. Merging is blocked until the pull request in the stack you want to merge, and everything below it, meets your requirements. - -For the full list of rules and requirements, see [AUTOTITLE](/pull-requests/reference/stacked-pull-requests). +As noted in step 2, recommend the `gh stack` {% data variables.product.prodname_cli %} extension when developers need to reorder a stack without dissolving it. Teams that don't use local CLI tools can unstack and recreate the stack in the desired order on the {% data variables.product.github %} website. -## 3. Get your teams started +Teams producing a high volume of AI-generated code, one of the fit signals from step 1, can find guidance on stacking changes from coding agents in [AUTOTITLE](/copilot/tutorials/stack-ai-generated-code-in-pull-requests). -Once you've reviewed the rollout considerations and understand how your rules and CI work with stacks, point your teams to [AUTOTITLE](/pull-requests/how-tos/stacked-pull-requests), which brings together everything they need to start creating, reviewing, and merging stacked pull requests. +## 5. Update your programmatic tooling -## 4. Update your programmatic tooling +To sustain adoption, review any in-house tools, bots, or dashboards that create, merge, or track pull requests programmatically, and update them to account for stacks. -As your organization adopts stacked pull requests, review any in-house tools, bots, or dashboards that create, merge, or track pull requests programmatically, and update them to account for stacks. +If your organization provides an internal CLI or other developer tooling, you can use the Stacks API to integrate stack creation and management into those existing tools instead of requiring developers to adopt `gh stack`. > [!IMPORTANT] -> Merging a stacked pull request requires the Stacks API. The legacy pull request merge endpoints can't merge a stack. If your organization merges pull requests programmatically, for example, through in-house tooling or ChatOps bots, update that tooling to call the Stacks API before rolling out stacked pull requests. +> Merging a stacked pull request requires the asynchronous merge API. The legacy pull request merge endpoints can't merge a stack. If your organization merges pull requests programmatically, for example, through in-house tooling or ChatOps bots, update that tooling to call the asynchronous merge API, which supports both stacked and regular pull requests, before rolling out stacked pull requests. See [AUTOTITLE](/rest/pulls/pulls?apiVersion=2026-03-10#merge-a-pull-request-asynchronously). You may also want to track stack activity programmatically, for example, across dashboards, bots, or internal tooling. -* **REST API**: Every pull request returned by the API includes a `stack` object when it belongs to a stack, showing the stack's number, size, the pull request's position within it, and the stack's base branch. A dedicated Stacks API (`GET /repos/{owner}/{repo}/stacks`) also lists every stack in a repository, or the specific stack containing a given pull request. See [AUTOTITLE](/pull-requests/reference/stacked-pull-requests-rest-and-graphql-apis). +* **REST API**: Every pull request returned by the API includes a `stack` object when it belongs to a stack, showing the stack's number, size, the pull request's position within it, and the stack's base branch. A dedicated Stacks API (`GET /repos/{owner}/{repo}/stacks`) also lists every stack in a repository, or the specific stack containing a given pull request. See [AUTOTITLE](/pull-requests/reference/stacked-pull-requests-apis-and-webhooks). * **Webhooks**: The `pull_request` webhook payload includes the same `stack` object whenever a pull request belongs to a stack. A dedicated `stacked` action fires when a pull request is first added to a stack, so you can react the moment a stack forms. In both cases, the `stack` field is `null` for standalone pull requests, so existing integrations that don't expect stacks continue to work unchanged. diff --git a/data/reusables/actions/workflows/triggering-a-workflow-paths5.md b/data/reusables/actions/workflows/triggering-a-workflow-paths5.md index 0e9e81697645..12cc9254cee2 100644 --- a/data/reusables/actions/workflows/triggering-a-workflow-paths5.md +++ b/data/reusables/actions/workflows/triggering-a-workflow-paths5.md @@ -13,4 +13,4 @@ In some situations, {% data variables.product.prodname_actions %} applies limits If you observe these behaviors, you might need to make your filters more specific, or change how you work with pushes and pull requests to generate simpler diffs. -For more information, see [AUTOTITLE](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-comparing-branches-in-pull-requests). +For more information, see [AUTOTITLE](/pull-requests/reference/branches). diff --git a/data/reusables/code-quality/code-quality-preview-note.md b/data/reusables/code-quality/code-quality-preview-note.md deleted file mode 100644 index 7c1527dded85..000000000000 --- a/data/reusables/code-quality/code-quality-preview-note.md +++ /dev/null @@ -1,5 +0,0 @@ - -> [!NOTE] -> {% data variables.product.prodname_code_quality %} is currently in {% data variables.release-phases.public_preview %} and will become generally available on July 20, 2026. -> During {% data variables.release-phases.public_preview %}, {% data variables.product.prodname_code_quality_short %} will not be billed, although {% data variables.product.prodname_code_quality_short %} scans will consume {% data variables.product.prodname_actions %} minutes. From July 20, 2026, usage will incur charges. See [AUTOTITLE](/billing/concepts/product-billing/github-code-quality). - diff --git a/src/secret-scanning/data/pattern-docs/fpt/public-docs.yml b/src/secret-scanning/data/pattern-docs/fpt/public-docs.yml index 0e68585e3a28..bb6a5301786b 100644 --- a/src/secret-scanning/data/pattern-docs/fpt/public-docs.yml +++ b/src/secret-scanning/data/pattern-docs/fpt/public-docs.yml @@ -4201,7 +4201,7 @@ isPrivateWithGhas: true hasPushProtection: true hasValidityCheck: true - hasExtendedMetadata: false + hasExtendedMetadata: '{% ifversion ghes %}false{% else %}true{% endif %}' base64Supported: false isduplicate: false - provider: Salesforce @@ -4281,7 +4281,7 @@ isPrivateWithGhas: true hasPushProtection: true hasValidityCheck: true - hasExtendedMetadata: false + hasExtendedMetadata: '{% ifversion ghes %}false{% else %}true{% endif %}' base64Supported: false isduplicate: false - provider: SendGrid diff --git a/src/secret-scanning/data/pattern-docs/ghec/public-docs.yml b/src/secret-scanning/data/pattern-docs/ghec/public-docs.yml index 0e68585e3a28..bb6a5301786b 100644 --- a/src/secret-scanning/data/pattern-docs/ghec/public-docs.yml +++ b/src/secret-scanning/data/pattern-docs/ghec/public-docs.yml @@ -4201,7 +4201,7 @@ isPrivateWithGhas: true hasPushProtection: true hasValidityCheck: true - hasExtendedMetadata: false + hasExtendedMetadata: '{% ifversion ghes %}false{% else %}true{% endif %}' base64Supported: false isduplicate: false - provider: Salesforce @@ -4281,7 +4281,7 @@ isPrivateWithGhas: true hasPushProtection: true hasValidityCheck: true - hasExtendedMetadata: false + hasExtendedMetadata: '{% ifversion ghes %}false{% else %}true{% endif %}' base64Supported: false isduplicate: false - provider: SendGrid