Repo sync

content/actions/tutorials/develop-agentic-workflows-in-github-actions.md

@@ -0,0 +1,111 @@
+---
+title: Develop agentic workflows in GitHub Actions
+shortTitle: Develop agentic workflows
+intro: 'Use {% data variables.copilot.github_agentic_workflows %} to turn Markdown instructions into automations powered by third-party coding agents.'
+versions:
+  feature: copilot
+contentType: tutorials
+category:
+  - Write workflows
+---
+
+{% data reusables.copilot.agentic-workflows-preview-note %}
+
+## Introduction
+
+{% data variables.copilot.github_agentic_workflows %} let you define repository automations in Markdown and choose the AI coding agent that runs them. The `gh aw` extension compiles each agentic workflow into a {% data variables.product.prodname_actions %} workflow.
+
+The entire workflow lifecycle—authoring, debugging, and optimization—is itself agentic. You describe what you want in natural language and a coding agent creates, refines, and troubleshoots the workflow for you.
+
+This tutorial uses a coding agent to create an automated pull request reviewer that checks whether changes are adequately tested.
+
+## Prerequisites
+
+Before you begin, make sure you have:
+
+* A repository where {% data variables.product.prodname_actions %} is enabled and you have write access
+* {% data variables.product.prodname_cli %} version 2.0.0 or later installed and authenticated
+* Access to a supported coding agent, such as {% data reusables.copilot.agentic-workflows-third-party-agent-clis %}, or {% data variables.copilot.copilot_cli_short %}, and its required credential
+
+To authenticate {% data variables.product.prodname_cli %}, run:
+
+```shell
+gh auth login --scopes repo,workflow
+```
+
+## Installing the `gh aw` extension
+
+Install the {% data variables.copilot.github_agentic_workflows %} extension for {% data variables.product.prodname_cli %}:
+
+```shell
+gh extension install github/gh-aw
+```
+
+## Choosing an agent and configuring authentication
+
+Choose the agent CLI that best fits your workflow. {% data reusables.copilot.agentic-workflows-third-party-agent-clis %}, and {% data variables.copilot.copilot_cli_short %} can all run {% data variables.copilot.github_agentic_workflows %}.
+
+This article walks through a simple setup that adds the agent's credential as a repository secret. If you use {% data reusables.copilot.agentic-workflows-third-party-agent-clis %}, store the agent's API key as a repository secret.
+
+| Agent CLI | `engine` value | Repository secret |
+| --- | --- | --- |
+| Claude Code | `claude` | `ANTHROPIC_API_KEY` containing an Anthropic API key |
+| {% data variables.product.prodname_openai_codex %} | `codex` | `OPENAI_API_KEY` containing an OpenAI API key |
+| Google {% data variables.copilot.copilot_gemini %} CLI | `gemini` | `GEMINI_API_KEY` containing a Google AI Studio API key |
+| {% data variables.copilot.copilot_cli_short %} (default) | `copilot` | No secret needed for organization repositories (see below). For personal repositories, `COPILOT_GITHUB_TOKEN` containing a fine-grained {% data variables.product.pat_generic %} with **Copilot Requests** set to **Read**. |
+
+Other engines such as Pi (experimental) are also supported. For the full list, see the [{% data variables.copilot.github_agentic_workflows %} authentication reference](https://github.github.com/gh-aw/reference/auth/).
+
+### Organization billing for {% data variables.product.prodname_copilot %}
+
+If you use {% data variables.product.prodname_copilot %} in an organization-owned repository, you can use {% data variables.product.prodname_actions %}' built-in `GITHUB_TOKEN` instead of a {% data variables.product.pat_generic %}. Add `copilot-requests: write` to your workflow frontmatter `permissions` and no separate secret is required. For setup steps, see [AUTOTITLE](/copilot/how-tos/github-agentic-workflows/creating-github-agentic-workflows#using-the-built-in-github_token).
+
+### Storing a secret in the GitHub UI
+
+To add a secret for {% data reusables.copilot.agentic-workflows-third-party-agent-clis %}, or {% data variables.product.prodname_copilot %} personal repositories:
+
+1. On {% data variables.product.github %}, navigate to your repository.
+1. Under your repository name, click **{% octicon "gear" aria-hidden="true" aria-label="gear" %} Settings**.
+1. In the sidebar, click **Secrets and variables**, then click **Actions**.
+1. Click **New repository secret**.
+1. In the **Name** field, enter the secret name from the table above.
+1. In the **Secret** field, enter the value.
+1. Click **Add secret**.
+
+## Creating the workflow
+
+Use a coding agent to create the workflow from a natural language description.
+
+1. From your repository root, initialize the repository for agentic authoring. This adds skills and instructions that help the coding agent create and edit workflows:
+
+   ```shell
+   gh aw init
+   ```
+
+1. Start a coding agent session in the context of your repository—for example, using {% data reusables.copilot.agentic-workflows-third-party-agent-clis %}, {% data variables.copilot.copilot_cli_short %}, or VS Code agent mode.
+1. Use the `agentic-workflows` skill and describe the workflow you want:
+
+   ```copilot copy
+   /agentic-workflows create a pr reviewer that ensure the changes are tested.
+   ```
+
+    The agent creates a workflow Markdown file in `.github/workflows/`, compiles the corresponding `.lock.yml` {% data variables.product.prodname_actions %} workflow file, and asks you to review and commit both files.
+
+1. Review the generated workflow, then ask the agent to commit and push the files.
+
+> [!TIP]
+> You can use the same agentic approach to update and improve the workflow after it runs. Ask the agent to refine the review criteria, add more checks, or debug a failed run—all in natural language. If you edit the workflow frontmatter later, run `gh aw compile` before committing your changes.
+
+## Running the workflow
+
+The generated workflow triggers automatically on pull requests, so it runs the next time you open or update a pull request in your repository.
+
+1. Open a pull request in your repository.
+1. On {% data variables.product.github %}, navigate to your repository and click the **Actions** tab.
+1. In the left sidebar, select the workflow that the agent created.
+1. Once the run completes, the workflow leaves a pull request review noting whether the changes include enough tests.
+
+## Next steps
+
+* To create a workflow that produces a weekly issue activity report, see [AUTOTITLE](/copilot/how-tos/github-agentic-workflows/creating-github-agentic-workflows).
+* For advanced engine configuration, safe outputs, and more workflow examples, see the [{% data variables.copilot.github_agentic_workflows %} documentation site](https://github.github.com/gh-aw/).

content/actions/tutorials/index.md

@@ -18,6 +18,7 @@ children:
   - /use-containerized-services
   - /migrate-to-github-actions
   - /use-actions-runner-controller
+  - /develop-agentic-workflows-in-github-actions
 redirect_from:
   - /actions/guides
   - /actions/how-tos/use-cases-and-examples
@@ -27,4 +28,3 @@ redirect_from:
   - /actions/use-cases-and-examples
 contentType: tutorials
 ---
-

content/admin/data-residency/network-details-for-ghecom.md

@@ -42,9 +42,24 @@ git clone SUBDOMAIN@SUBDOMAIN.ghe.com:OWNER/REPO.git
 * `*.actions.{% data variables.enterprise.data_residency_domain %}`
 * `*.githubassets.com`
 * `*.githubusercontent.com`
-* `*.blob.core.windows.net`
+* `*.blob.core.windows.net`. If you cannot allow access to wildcard domains, see [Azure Blob Storage hostnames](#azure-blob-storage-hostnames).
 * `auth.ghe.com`
 
+### Azure Blob Storage hostnames
+
+If you cannot allow access to `*.blob.core.windows.net`, use the `/meta` API endpoint for your enterprise to retrieve the complete list of client-facing Azure Blob Storage hostnames. For example, using the {% data variables.product.prodname_cli %}:
+
+```shell
+gh api /meta --hostname octocorp.ghe.com --jq '.domains.storage[]'
+```
+
+Allow access to every hostname returned in `domains.storage`. The list is specific to your enterprise and {% data variables.product.company_short %} keeps it up to date as network requirements change.
+
+For more information about the `/meta` endpoint, see [AUTOTITLE](/rest/meta/meta#get-github-meta-information).
+
+> [!NOTE]
+> If you stream audit logs to your own Azure Blob Storage destination, you must allow access to that destination separately.
+
 ## {% data variables.product.github %}'s IP addresses
 
 {% data variables.product.company_short %}'s IP address ranges for enterprises on {% data variables.enterprise.data_residency_site %} depend on your chosen region.
@@ -204,41 +219,9 @@ Japan region:
 * `<TENANT>.ghe.com`
 * `github.com`
 * `*.githubusercontent.com`
-* `*.blob.core.windows.net` (can be further restricted by region, see below)
+* `*.blob.core.windows.net`. To allow access only to the hostnames used by your enterprise, see [Azure Blob Storage hostnames](#azure-blob-storage-hostnames).
 * `*.web.core.windows.net`
 
-#### EU
-
-`*.blob.core.windows.net` can be replaced with:
-* `memoryalphaprodsdc01.blob.core.windows.net`
-* `memoryalphaprodweu01.blob.core.windows.net`
-* `prodsdc01resultssa0.blob.core.windows.net`
-* `prodsdc01resultssa1.blob.core.windows.net`
-* `prodsdc01resultssa2.blob.core.windows.net`
-* `prodsdc01resultssa3.blob.core.windows.net`
-* `prodweu01resultssa0.blob.core.windows.net`
-* `prodweu01resultssa1.blob.core.windows.net`
-* `prodweu01resultssa2.blob.core.windows.net`
-* `prodweu01resultssa3.blob.core.windows.net` 
-
-#### Australia
-
-`*.blob.core.windows.net` can be replaced with:
-* `memoryalphaprodae01.blob.core.windows.net`
-* `prodae01resultssa0.blob.core.windows.net`
-* `prodae01resultssa1.blob.core.windows.net`
-* `prodae01resultssa2.blob.core.windows.net`
-* `prodae01resultssa3.blob.core.windows.net`
-
-#### Japan
-
-`*.blob.core.windows.net` can be replaced with:
-* `memoryalphaprodjpw01.blob.core.windows.net`
-* `prodjpw01resultssa0.blob.core.windows.net`
-* `prodjpw01resultssa1.blob.core.windows.net`
-* `prodjpw01resultssa2.blob.core.windows.net`
-* `prodjpw01resultssa3.blob.core.windows.net`
-
 ### OAuth callback URL for connecting an Azure subscription for billing
 
 When you connect or update an Azure subscription for billing, you must allow access to the following URL:

content/communities/moderating-comments-and-conversations/limiting-interactions-in-your-organization.md

@@ -38,6 +38,24 @@ Organization owners and moderators can also block users for a specific amount of
 
 {% data reusables.community.set-interaction-limit %}
 
+{% ifversion pull-request-limit %}
+
+## Limiting concurrent open pull requests for users without write access
+
+Across all public repositories owned by your organization, you can set a maximum number of pull requests that a user without write access can have open at the same time. This limit applies separately to each repository, so a user without write access can have up to the configured maximum number of open pull requests in _each_ public repository owned by the organization, not across the organization as a whole. When a user without write access reaches the limit in a repository, they must close an existing pull request or wait for someone with write access to merge one before they can open a new one.
+
+This setting helps maintainers manage contribution volume by preventing users from opening an excessive number of pull requests, which can overwhelm review queues and trigger unnecessary CI runs. The limit only applies to users without write access—users with write access or higher are not affected.
+
+Draft pull requests do not count toward a user's limit. Only open, non-draft pull requests are counted when determining whether a user has reached the maximum.
+
+The organization-level limit takes precedence, but if a repository owned by your organization has its own pull request limit configured after the organization-level limit, the repository-level limit overrides the organization-level limit. See [AUTOTITLE](/communities/moderating-comments-and-conversations/limiting-interactions-in-your-repository#limiting-concurrent-open-pull-requests-for-users-without-write-access).
+
+### Configuring the pull request limit
+
+To configure the pull request limit, navigate to the **Interaction limits** settings page following the same steps described in [Limiting interactions in your organization](#limiting-interactions-in-your-organization), then under **Pull request limits**, select the maximum number of concurrent open pull requests allowed for users without write access. You can also use the REST API to configure the pull request limit. See [AUTOTITLE](/rest/interactions/orgs#update-pull-request-creation-cap-for-an-org).
+
+{% endif %}
+
 ## Further reading
 
 * [AUTOTITLE](/communities/maintaining-your-safety-on-github/reporting-abuse-or-spam)

content/communities/moderating-comments-and-conversations/limiting-interactions-in-your-repository.md

@@ -31,6 +31,8 @@ You can also enable activity limitations on all repositories owned by your perso
 1. In the sidebar, select **{% octicon "comment-discussion" aria-hidden="true" aria-label="comment-discussion" %} Moderation options**, then click **Interaction limits**.
 {% data reusables.community.set-interaction-limit %}
 
+{% ifversion pull-request-limit %}
+
 ## Limiting concurrent open pull requests for users without write access
 
 In a public repository, you can set a maximum number of pull requests that a user without write access can have open at the same time. When a user without write access reaches the limit, they can close or merge an existing pull request before they can open a new one.
@@ -52,6 +54,8 @@ To configure the pull request limit, navigate to the **Interaction limits** sett
 1. Under **Pull request limits**, select the maximum number of concurrent open pull requests allowed for users without write access.
 1. Optionally, under **Bypass list**, search for and select the users you want to allow to bypass the pull request limit.
 
+{% endif %}
+
 ## Further reading
 
 * [AUTOTITLE](/communities/maintaining-your-safety-on-github/reporting-abuse-or-spam)