repo sync

.github/workflows/triage-stale-check.yml

@@ -7,7 +7,7 @@ name: Public Repo Stale Check
 on:
   schedule:
     - cron: '45 16 * * *' # Run each day at 16:45 UTC / 8:45 PST
-    
+
 permissions:
   issues: write
   pull-requests: write

content/github-cli/github-cli/creating-github-cli-extensions.md

@@ -14,15 +14,21 @@ topics:
 
 {% data reusables.cli.cli-extensions %} For more information about how to use {% data variables.product.prodname_cli %} extensions, see "[Using {% data variables.product.prodname_cli %} extensions](/github-cli/github-cli/using-github-cli-extensions)."
 
-You need a repository for each extension that you create. The repository name must start with `gh-`. The rest of the repository name is the name of the extension. At the root of the repository, there must be an executable file with the same name as the repository. This file will be executed when the extension is invoked.
+You need a repository for each extension that you create. The repository name must start with `gh-`. The rest of the repository name is the name of the extension. The repository must have an executable file at its root with the same name as the repository or a set of precompiled binary executables attached to a release.
 
 {% note %}
 
-**Note**: We recommend that the executable file is a bash script because bash is a widely available interpreter. You may use non-bash scripts, but the user must have the necessary interpreter installed in order to use the extension.
+**Note**: When relying on an executable script, we recommend using a bash script because bash is a widely available interpreter. You may use non-bash scripts, but the user must have the necessary interpreter installed in order to use the extension. If you would prefer to not rely on users having interpreters installed, consider a precompiled extension.
 
 {% endnote %}
 
-## Creating an extension with `gh extension create`
+## Creating an interpreted extension with `gh extension create`
+
+{% note %}
+
+**Note**: Running `gh extension create` with no arguments will start an interactive wizard.
+
+{% endnote %}
 
 You can use the `gh extension create` command to create a project for your extension, including a bash script that contains some starter code.
 
@@ -34,7 +40,35 @@ You can use the `gh extension create` command to create a project for your exten
 
 1. Follow the printed instructions to finalize and optionally publish your extension.
 
-## Creating an extension manually
+## Creating a precompiled extension in Go with `gh extension create`
+
+You can use the `--precompiled=go` argument to create a Go-based project for your extension, including Go scaffolding, workflow scaffolding, and starter code.
+
+1. Set up a new extension by using the `gh extension create` subcommand. Replace `EXTENSION-NAME` with the name of your extension and specify `--precompiled=go`.
+
+    ```shell
+    gh extension create --precompiled=go <em>EXTENSION-NAME</em>
+    ```
+
+1. Follow the printed instructions to finalize and optionally publish your extension.
+
+## Creating a non-Go precompiled extension with `gh extension create`
+
+You can use the `--precompiled=other` argument to create a project for your non-Go precompiled extension, including workflow scaffolding.
+
+1. Set up a new extension by using the `gh extension create` subcommand. Replace `EXTENSION-NAME` with the name of your extension and specify `--precompiled=other`.
+
+    ```shell
+    gh extension create --precompiled=other <em>EXTENSION-NAME</em>
+    ```
+
+1. Add some initial code for your extension in your compiled language of choice.
+
+1. Fill in `script/build.sh` with code to build your extension to ensure that your extension can be built automatically.
+
+1. Follow the printed instructions to finalize and optionally publish your extension.
+
+## Creating an interpreted extension manually
 
 1. Create a local directory called `gh-EXTENSION-NAME` for your extension. Replace `EXTENSION-NAME` with the name of your extension. For example, `gh-whoami`.
 
@@ -56,7 +90,7 @@ You can use the `gh extension create` command to create a project for your exten
 
 1. From your directory, install the extension as a local extension.
 
-   ```bash
+   ```shell
    gh extension install .
    ```
 
@@ -70,13 +104,13 @@ You can use the `gh extension create` command to create a project for your exten
 
    ```shell
    git init -b main
-   git add . && git commit -m "initial commit" 
-   gh repo create gh-<em>EXTENSION-NAME</em> --source=. --public --push 
+   git add . && git commit -m "initial commit"
+   gh repo create gh-<em>EXTENSION-NAME</em> --source=. --public --push
    ```
 
 1. Optionally, to help other users discover your extension, add the repository topic `gh-extension`. This will make the extension appear on the [`gh-extension` topic page](https://github.com/topics/gh-extension). For more information about how to add a repository topic, see "[Classifying your repository with topics](/github/administering-a-repository/managing-repository-settings/classifying-your-repository-with-topics)."
 
-## Tips for writing {% data variables.product.prodname_cli %} extensions
+## Tips for writing interpreted {% data variables.product.prodname_cli %} extensions
 
 ### Handling arguments and flags
 
@@ -120,34 +154,128 @@ fi
 
 ### Calling core commands in non-interactive mode
 
-Some {% data variables.product.prodname_cli %} core commands will prompt the user for input. When scripting with those commands, a prompt is often undesirable. To avoid prompting, supply the necessary information explicitly via arguments. 
+Some {% data variables.product.prodname_cli %} core commands will prompt the user for input. When scripting with those commands, a prompt is often undesirable. To avoid prompting, supply the necessary information explicitly via arguments.
 
 For example, to create an issue programmatically, specify the title and body:
 
-```bash
+```shell
 gh issue create --title "My Title" --body "Issue description"
 ```
 
 ### Fetching data programatically
 
 Many core commands support the `--json` flag for fetching data programatically. For example, to return a JSON object listing the number, title, and mergeability status of pull requests:
-```bash
+
+```shell
 gh pr list --json number,title,mergeStateStatus
 ```
 
 If there is not a core command to fetch specific data from GitHub, you can use the [`gh api`](https://cli.github.com/manual/gh_api) command to access the GitHub API. For example, to fetch information about the current user:
-```bash
+
+```shell
 gh api user
 ```
 
 All commands that output JSON data also have options to filter that data into something more immediately usable by scripts. For example, to get the current user's name:
 
-```bash
+```shell
 gh api user --jq '.name'
 ```
 
 For more information, see [`gh help formatting`](https://cli.github.com/manual/gh_help_formatting).
 
+## Creating a precompiled extension manually
+
+1. Create a local directory called `gh-EXTENSION-NAME` for your extension. Replace `EXTENSION-NAME` with the name of your extension. For example, `gh-whoami`.
+
+1. In the directory you created, add some source code. For example:
+
+    ```go
+    package main
+    import (
+      "github.com/cli/go-gh"
+      "fmt"
+    )
+
+    func main() {
+      args := []string{"api", "user", "--jq", `"You are @\(.login) (\(.name))"` }
+      stdOut, _, err := gh.Exec(args...)
+      if err != nil {
+        fmt.Println(err)
+        return
+      }
+      fmt.Println(stdOut.String())
+    }
+    ```
+
+1. From your directory, install the extension as a local extension.
+
+    ```shell
+    gh extension install .
+    ```
+
+1. Build your code. For example, with Go, replacing `YOUR-USERNAME` with your GitHub username:
+
+    ```shell
+    go mod init github.com/<em>YOUR-USERNAME</em>/gh-whoami
+    go mod tidy
+    go build
+    ```
+
+1. Verify that your extension works. Replace `EXTENSION-NAME` with the name of your extension. For example, `whoami`.
+
+    ```shell
+    gh <em>EXTENSION-NAME</em>
+    ```
+
+1. From your directory, create a repository to publish your extension. Replace `EXTENSION-NAME` with the name of your extension.
+
+  {% note %}
+
+  **Note:** Be careful not to commit the binary produced by your compilation step to version control.
+
+  {% endnote %}
+
+    ```shell
+    git init -b main
+    echo "gh-<em>EXTENSION-NAME</em>" >> .gitignore
+    git add main.go go.* .gitignore && git commit -m'Initial commit'
+    gh repo create "gh-<em>EXTENSION-NAME</em>"
+    ```
+
+1. Create a release to share your precompiled extension with others. Compile for each platform you want to support, attaching each binary to a release as an asset. Binary executables attached to releases must follow a naming convention and have a suffix of <em>OS-ARCHITECTURE\[EXTENSION\]</em>.
+
+  For example, an extension named `whoami` compiled for Windows 64bit would have the name `gh-whoami-windows-amd64.exe` while the same extension compiled for Linux 32bit would have the name `gh-whoami-linux-386`. To see an exhaustive list of OS and architecture combinations recognized by `gh`, see [this source code](https://github.com/cli/cli/blob/14f704fd0da58cc01413ee4ba16f13f27e33d15e/pkg/cmd/extension/manager.go#L696).
+
+  {% note %}
+
+  **Note:** For your extension to run properly on Windows, its asset file must have a `.exe` extension. No extension is needed for other operating systems.
+
+  {% endnote %}
+
+  Releases can be created from the command line. For example:
+
+  ```shell
+  git tag v1.0.0
+  git push origin v1.0.0
+  GOOS=windows GOARCH=amd64 go build -o gh-<em>EXTENSION-NAME</em>-windows-amd64.exe
+  GOOS=linux GOARCH=amd64 go build -o gh-<em>EXTENSION-NAME</em>-linux-amd64
+  GOOS=darwin GOARCH=amd64 go build -o gh-<em>EXTENSION-NAME</em>-darwin-amd64
+  gh release create v1.0.0 ./*amd64*
+
+1. Optionally, to help other users discover your extension, add the repository topic `gh-extension`. This will make the extension appear on the [`gh-extension` topic page](https://github.com/topics/gh-extension). For more information about how to add a repository topic, see "[Classifying your repository with topics](/github/administering-a-repository/managing-repository-settings/classifying-your-repository-with-topics)."
+
+
+## Tips for writing precompiled {% data variables.product.prodname_cli %} extensions
+
+### Automating releases
+
+Consider adding the [gh-extension-precompile](https://github.com/cli/gh-extension-precompile) action to a workflow in your project. This action will automatically produce cross-compiled Go binaries for your extension and supplies build scaffolding for non-Go precompiled extensions.
+
+### Using {% data variables.product.prodname_cli %} features from Go-based extensions
+
+Consider using [go-gh](https://github.com/cli/go-gh), a Go library that exposes pieces of `gh` functionality for use in extensions.
+
 ## Next steps
 
 To see more examples of {% data variables.product.prodname_cli %} extensions, look at [repositories with the `gh-extension` topic](https://github.com/topics/gh-extension).

translations/es-ES/content/actions/creating-actions/releasing-and-maintaining-actions.md

@@ -9,6 +9,7 @@ topics:
   - Community
 versions:
   fpt: '*'
+  ghec: '*'
   ghes: '*'
   ghae: '*'
 ---
@@ -37,7 +38,7 @@ JavaScript actions are Node.js repositories with metadata. However, JavaScript a
 
 * Dependent packages are committed alongside the code, typically in a compiled and minified form. This means that automated builds and secure community contributions are important.
 
-{% ifversion fpt %}
+{% ifversion fpt or ghec %}
 
 * Tagged releases can be published directly to {% data variables.product.prodname_marketplace %} and consumed by workflows across {% data variables.product.prodname_dotcom %}.
 
@@ -54,7 +55,7 @@ To support the developer process in the next section, add two {% data variables.
 
 ### Example developer process
 
-Here is an example process that you can follow to automatically run tests, create a release{% ifversion fpt%} and publish to {% data variables.product.prodname_marketplace %}{% endif %}, and publish your action.
+Here is an example process that you can follow to automatically run tests, create a release{% ifversion fpt or ghec%} and publish to {% data variables.product.prodname_marketplace %}{% endif %}, and publish your action.
 
 1. Do feature work in branches per GitHub flow. For more information, see "[GitHub flow](/get-started/quickstart/github-flow)."
    * Whenever a commit is pushed to the feature branch, your testing workflow will automatically run the tests.
@@ -65,7 +66,7 @@ Here is an example process that you can follow to automatically run tests, creat
 
    * **Note:** for security reasons, workflows triggered by `pull_request` from forks have restricted `GITHUB_TOKEN` permissions and do not have access to secrets. If your tests or other workflows triggered upon pull request require access to secrets, consider using a different event like a [manual trigger](/actions/reference/events-that-trigger-workflows#manual-events) or a [`pull_request_target`](/actions/reference/events-that-trigger-workflows#pull_request_target). Read more [here](/actions/reference/events-that-trigger-workflows#pull-request-events-for-forked-repositories).
 
-3. Create a semantically tagged release. {% ifversion fpt %} You may also publish to {% data variables.product.prodname_marketplace %} with a simple checkbox. {% endif %} For more information, see "[Managing releases in a repository](/github/administering-a-repository/managing-releases-in-a-repository#creating-a-release)"{% ifversion fpt %} and "[Publishing actions in {% data variables.product.prodname_marketplace %}](/actions/creating-actions/publishing-actions-in-github-marketplace#publishing-an-action)"{% endif %}.
+3. Create a semantically tagged release. {% ifversion fpt or ghec %} You may also publish to {% data variables.product.prodname_marketplace %} with a simple checkbox. {% endif %} For more information, see "[Managing releases in a repository](/github/administering-a-repository/managing-releases-in-a-repository#creating-a-release)"{% ifversion fpt or ghec %} and "[Publishing actions in {% data variables.product.prodname_marketplace %}](/actions/creating-actions/publishing-actions-in-github-marketplace#publishing-an-action)"{% endif %}.
 
    * When a release is published or edited, your release workflow will automatically take care of compilation and adjusting tags.
 
@@ -82,7 +83,7 @@ Using semantic releases means that the users of your actions can pin their workf
 {% data variables.product.product_name %} provides tools and guides to help you work with the open source community. Here are a few tools we recommend setting up for healthy bidirectional communication. By providing the following signals to the community, you encourage others to use, modify, and contribute to your action:
 
 * Maintain a `README` with plenty of usage examples and guidance. For more information, see "[About READMEs](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes)."
-* Include a workflow status badge in your `README` file. For more information, see "[Adding a workflow status badge](/actions/managing-workflow-runs/adding-a-workflow-status-badge)." Also visit [shields.io](https://shields.io/) to learn about other badges that you can add.{% ifversion fpt %}
+* Include a workflow status badge in your `README` file. For more information, see "[Adding a workflow status badge](/actions/managing-workflow-runs/adding-a-workflow-status-badge)." Also visit [shields.io](https://shields.io/) to learn about other badges that you can add.{% ifversion fpt or ghec %}
 * Add community health files like `CODE_OF_CONDUCT`, `CONTRIBUTING`, and `SECURITY`. For more information, see "[Creating a default community health file](/github/building-a-strong-community/creating-a-default-community-health-file#supported-file-types)."{% endif %}
 * Keep issues current by utilizing actions like [actions/stale](https://github.com/actions/stale).
 

translations/es-ES/content/actions/deployment/targeting-different-environments/using-environments-for-deployment.md

@@ -26,7 +26,9 @@ You can configure environments with protection rules and secrets. When a workflo
 {% ifversion fpt %}
 {% note %}
 
-**Note:** If you don't use {% data variables.product.prodname_ghe_cloud %} and convert a repository from public to private, any configured protection rules or environment secrets will be ignored, and you will not be able to configure any environments. If you convert your repository back to public, you will have access to any previously configured protection rules and environment secrets. {% data reusables.enterprise.link-to-ghec-trial %}
+**Note:** You can only configure environments for public repositories. If you convert a repository from public to private, any configured protection rules or environment secrets will be ignored, and you will not be able to configure any environments. If you convert your repository back to public, you will have access to any previously configured protection rules and environment secrets.
+
+Organizations that use {% data variables.product.prodname_ghe_cloud %} can configure environments for private repositories. For more information, see the [{% data variables.product.prodname_ghe_cloud %} documentation](/enterprise-cloud@latest/actions/deployment/targeting-different-environments/using-environments-for-deployment). {% data reusables.enterprise.link-to-ghec-trial %}
 
 {% endnote %}
 {% endif %}

translations/es-ES/content/actions/guides.md

@@ -65,3 +65,4 @@ includeGuides:
   - /code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/automating-dependabot-with-github-actions
   - /code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/keeping-your-actions-up-to-date-with-dependabot
 ---
+

translations/es-ES/content/actions/hosting-your-own-runners/adding-self-hosted-runners.md

@@ -81,11 +81,13 @@ You can add self-hosted runners at the organization level, where they can be use
 
 ## Adding a self-hosted runner to an enterprise
 
-You can add self-hosted runners to an enterprise, where they can be assigned to multiple organizations. The organization admins are then able to control which repositories can use it.
+{% ifversion fpt %}If you use {% data variables.product.prodname_ghe_cloud %}, you{% elsif ghec or ghes or ghae %}You{% endif %} can add self-hosted runners to an enterprise, where they can be assigned to multiple organizations. The organization admins are then able to control which repositories can use it. {% ifversion fpt %}For more information, see the [{% data variables.product.prodname_ghe_cloud %} documentation](/enterprise-cloud@latest/actions/hosting-your-own-runners/adding-self-hosted-runners#adding-a-self-hosted-runner-to-an-enterprise).{% endif %}
+
+{% ifversion ghec or ghes or ghae %}
 
 New runners are assigned to the default group. You can modify the runner's group after you've registered the runner. For more information, see "[Managing access to self-hosted runners](/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups#moving-a-self-hosted-runner-to-a-group)."
 
-{% ifversion fpt or ghec %}
+{% ifversion ghec %}
 To add a self-hosted runner to an enterprise account, you must be an enterprise owner. For information about how to add a self-hosted runner with the REST API, see the [Enterprise Administration GitHub Actions APIs](/rest/reference/enterprise-admin#github-actions).
 
 {% data reusables.enterprise-accounts.access-enterprise %}
@@ -104,9 +106,11 @@ To add a self-hosted runner at the enterprise level of {% data variables.product
 1. Click **Add new**, then click **New runner**.
 {% data reusables.github-actions.self-hosted-runner-configure %}
 {% endif %}
+{% ifversion ghec or ghae or ghes %}
 {% data reusables.github-actions.self-hosted-runner-check-installation-success %}
 
 {% data reusables.github-actions.self-hosted-runner-public-repo-access %}
+{% endif %}
 
 ### Making enterprise runners available to repositories
 
@@ -115,3 +119,4 @@ By default, runners in an enterprise's "Default" self-hosted runner group are av
 To make an enterprise-level self-hosted runner group available to an organization repository, you might need to change the organization's inherited settings for the runner group to make the runner available to repositories in the organization.
 
 For more information on changing runner group access settings, see "[Managing access to self-hosted runners using groups](/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups#changing-the-access-policy-of-a-self-hosted-runner-group)."
+{% endif %}