jprdonnelly/docs
1
0
Fork 0
mirror of synced 2026-01-06 15:01:04 -05:00
Code Issues Projects Releases Wiki Activity

New translation batch for pt (#28578)

Browse Source 
* Add crowdin translations

* Run script/i18n/homogenize-frontmatter.js

* Run script/i18n/fix-translation-errors.js

* Run script/i18n/lint-translation-files.js --check rendering

* run script/i18n/reset-files-with-broken-liquid-tags.js --language=pt

* run script/i18n/reset-known-broken-translation-files.js

Co-authored-by: Grace Park <gracepark@github.com>
This commit is contained in:
docubot
2022-06-16 18:23:23 -04:00
committed by GitHub
parent 93a5723d40
commit 32f3c24a80
12 changed files with 569 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
translations/pt-BR/content/actions/deployment/deploying-to-your-cloud-provider/deploying-to-azure/deploying-docker-to-azure-app-service.md
View File

@@ -138,10 +138,10 @@ jobs:
- name: Deploy to Azure Web App
id: deploy-to-webapp
uses: azure/webapps-deploy@0b651ed7546ecfc75024011f76944cb9b381ef1e
with:
app-name: {% raw %}${{ env.AZURE_WEBAPP_NAME }}{% endraw %}
publish-profile: {% raw %}${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}{% endraw %}
images: 'ghcr.io/{% raw %}${{ env.REPO }}{% endraw %}:{% raw %}${{ github.sha }}{% endraw %}'
with:
app-name: {% raw %}${{ env.AZURE_WEBAPP_NAME }}{% endraw %}
publish-profile: {% raw %}${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}{% endraw %}
images: 'ghcr.io/{% raw %}${{ env.REPO }}{% endraw %}:{% raw %}${{ github.sha }}{% endraw %}'
```
## Recursos adicionais

530
translations/pt-BR/content/actions/hosting-your-own-runners/customizing-the-containers-used-by-jobs.md Normal file
View File

@@ -0,0 +1,530 @@
---
title: Customizing the containers used by jobs
intro: You can customize how your self-hosted runner invokes a container for a job.
versions:
feature: container-hooks
type: reference
miniTocMaxHeadingLevel: 4
shortTitle: Customize containers used by jobs
---
{% note %}
**Observação**: Este recurso está atualmente na versão beta e está sujeito a alterações.
{% endnote %}
## About container customization
{% data variables.product.prodname_actions %} allows you to run a job within a container, using the `container:` statement in your workflow file. For more information, see "[Running jobs in a container](/actions/using-jobs/running-jobs-in-a-container)." To process container-based jobs, the self-hosted runner creates a container for each job.
{% data variables.product.prodname_actions %} supports commands that let you customize the way your containers are created by the self-hosted runner. For example, you can use these commands to manage the containers through Kubernetes or Podman, and you can also customize the `docker run` or `docker create` commands used to invoke the container. The customization commands are run by a script, which is automatically triggered when a specific environment variable is set on the runner. For more information, see "[Triggering the customization script](#triggering-the-customization-script)" below.
This customization is only available for Linux-based self-hosted runners, and root user access is not required.
## Container customization commands
{% data variables.product.prodname_actions %} includes the following commands for container customization:
- [`prepare_job`](/actions/hosting-your-own-runners/customizing-the-containers-used-by-jobs#prepare_job): Called when a job is started.
- [`cleanup_job`](/actions/hosting-your-own-runners/customizing-the-containers-used-by-jobs#cleanup_job): Called at the end of a job.
- [`run_container_step`](/actions/hosting-your-own-runners/customizing-the-containers-used-by-jobs#run_container_step): Called once for each container action in the job.
- [`run_script_step`](/actions/hosting-your-own-runners/customizing-the-containers-used-by-jobs#run_script_step): Runs any step that is not a container action.
Each of these customization commands must be defined in its own JSON file. The file name must match the command name, with the extension `.json`. For example, the `prepare_job` command is defined in `prepare_job.json`. These JSON files will then be run together on the self-hosted runner, as part of the main `index.js` script. This process is described in more detail in "[Generating the customization script](#generating-the-customization-script)."
These commands also include configuration arguments, explained below in more detail.
### `prepare_job`
The `prepare_job` command is called when a job is started. {% data variables.product.prodname_actions %} passes in any job or service containers the job has. This command will be called if you have any service or job containers in the job.
{% data variables.product.prodname_actions %} assumes that you will do the following tasks in the `prepare_job` command:
- Prune anything from previous jobs, if needed.
- Create a network, if needed.
- Pull the job and service containers.
- Start the job container.
- Start the service containers.
- Write to the response file any information that {% data variables.product.prodname_actions %} will need:
- Required: State whether the container is an `alpine` linux container (using the `isAlpine` boolean).
- Optional: Any context fields you want to set on the job context, otherwise they will be unavailable for users to use. For more information, see "[`job` context](/actions/learn-github-actions/contexts#job-context)."
- Return `0` when the health checks have succeeded and the job/service containers are started.
#### Argumentos
- `jobContainer`: **Optional**. An object containing information about the specified job container.
- `image`: **Required**. A string containing the Docker image.
- `workingDirectory`: **Required**. A string containing the absolute path of the working directory.
- `createOptions`: **Optional**. The optional _create_ options specified in the YAML. For more information, see "[Example: Running a job within a container](/actions/using-jobs/running-jobs-in-a-container#example-running-a-job-within-a-container)."
- `environmentVariables`: **Optional**. Sets a map of key environment variables.
- `userMountVolumes`: **Optional**. An array of user mount volumes set in the YAML. For more information, see "[Example: Running a job within a container](/actions/using-jobs/running-jobs-in-a-container#example-running-a-job-within-a-container)."
- `sourceVolumePath`: **Required**. The source path to the volume that will be mounted into the Docker container.
- `targetVolumePath`: **Required**. The target path to the volume that will be mounted into the Docker container.
- `readOnly`: **Required**. Determines whether or not the mount should be read-only.
- `systemMountVolumes`: **Required**. An array of mounts to mount into the container, same fields as above.
- `sourceVolumePath`: **Required**. The source path to the volume that will be mounted into the Docker container.
- `targetVolumePath`: **Required**. The target path to the volume that will be mounted into the Docker container.
- `readOnly`: **Required**. Determines whether or not the mount should be read-only.
- `registro` **Optional**. The Docker registry credentials for a private container registry.
- `username`: **Optional**. The username of the registry account.
- `password`: **Optional**. The password to the registry account.
- `serverUrl`: **Optional**. The registry URL.
- `portMappings`: **Optional**. A key value hash of _source:target_ ports to map into the container.
- `services`: **Optional**. An array of service containers to spin up.
- `contextName`: **Required**. The name of the service in the Job context.
- `image`: **Required**. A string containing the Docker image.
- `createOptions`: **Optional**. The optional _create_ options specified in the YAML. For more information, see "[Example: Running a job within a container](/actions/using-jobs/running-jobs-in-a-container#example-running-a-job-within-a-container)."
- `environmentVariables`: **Optional**. Sets a map of key environment variables.
- `userMountVolumes`: **Optional**. An array of mounts to mount into the container, same fields as above.
- `sourceVolumePath`: **Required**. The source path to the volume that will be mounted into the Docker container.
- `targetVolumePath`: **Required**. The target path to the volume that will be mounted into the Docker container.
- `readOnly`: **Required**. Determines whether or not the mount should be read-only.
- `registro` **Optional**. The Docker registry credentials for the private container registry.
- `username`: **Optional**. The username of the registry account.
- `password`: **Optional**. The password to the registry account.
- `serverUrl`: **Optional**. The registry URL.
- `portMappings`: **Optional**. A key value hash of _source:target_ ports to map into the container.
#### Example input
```json{:copy}
{
"command": "prepare_job",
"responseFile": "/users/octocat/runner/_work/{guid}.json",
"state": {},
"args": {
"jobContainer": {
"image": "node:14.16",
"workingDirectory": "/__w/octocat-test2/octocat-test2",
"createOptions": "--cpus 1",
"environmentVariables": {
"NODE_ENV": "development"
},
"userMountVolumes": [
{
"sourceVolumePath": "my_docker_volume",
"targetVolumePath": "/volume_mount",
"readOnly": false
}
],
"systemMountVolumes": [
{
"sourceVolumePath": "/home/octocat/git/runner/_layout/_work",
"targetVolumePath": "/__w",
"readOnly": false
},
{
"sourceVolumePath": "/home/octocat/git/runner/_layout/externals",
"targetVolumePath": "/__e",
"readOnly": true
},
{
"sourceVolumePath": "/home/octocat/git/runner/_layout/_work/_temp",
"targetVolumePath": "/__w/_temp",
"readOnly": false
},
{
"sourceVolumePath": "/home/octocat/git/runner/_layout/_work/_actions",
"targetVolumePath": "/__w/_actions",
"readOnly": false
},
{
"sourceVolumePath": "/home/octocat/git/runner/_layout/_work/_tool",
"targetVolumePath": "/__w/_tool",
"readOnly": false
},
{
"sourceVolumePath": "/home/octocat/git/runner/_layout/_work/_temp/_github_home",
"targetVolumePath": "/github/home",
"readOnly": false
},
{
"sourceVolumePath": "/home/octocat/git/runner/_layout/_work/_temp/_github_workflow",
"targetVolumePath": "/github/workflow",
"readOnly": false
}
],
"registry": {
"username": "octocat",
"password": "examplePassword",
"serverUrl": "https://index.docker.io/v1"
},
"portMappings": { "80": "801" }
},
"services": [
{
"contextName": "redis",
"image": "redis",
"createOptions": "--cpus 1",
"environmentVariables": {},
"userMountVolumes": [],
"portMappings": { "80": "801" },
"registry": {
"username": "octocat",
"password": "examplePassword",
"serverUrl": "https://index.docker.io/v1"
}
}
]
}
}
```
#### Example output
This example output is the contents of the `responseFile` defined in the input above.
```json{:copy}
{
"state": {
"network": "example_network_53269bd575972817b43f7733536b200c",
"jobContainer": "82e8219701fe096a35941d869cf3d71af1d943b5d8bdd718857fb87ac3042480",
"serviceContainers": {
"redis": "60972d9aa486605e66b0dad4abb678dc3d9116f536579e418176eedb8abb9105"
}
},
"context": {
"container": {
"id": "82e8219701fe096a35941d869cf3d71af1d943b5d8bdd718857fb87ac3042480",
"network": "example_network_53269bd575972817b43f7733536b200c"
},
"services": {
"redis": {
"id": "60972d9aa486605e66b0dad4abb678dc3d9116f536579e418176eedb8abb9105",
"ports": {
"8080": "8080"
},
"network": "example_network_53269bd575972817b43f7733536b200c"
}
},
"isAlpine": true
}
}
```
### `cleanup_job`
The `cleanup_job` command is called at the end of a job. {% data variables.product.prodname_actions %} assumes that you will do the following tasks in the `cleanup_job` command:
- Stop any running service or job containers (or the equivalent pod).
- Stop the network (if one exists).
- Delete any job or service containers (or the equivalent pod).
- Delete the network (if one exists).
- Cleanup anything else that was created for the job.
#### Argumentos
No arguments are provided for `cleanup_job`.
#### Example input
```json{:copy}
{
"command": "cleanup_job",
"responseFile": null,
"state": {
"network": "example_network_53269bd575972817b43f7733536b200c",
"jobContainer": "82e8219701fe096a35941d869cf3d71af1d943b5d8bdd718857fb87ac3042480",
"serviceContainers": {
"redis": "60972d9aa486605e66b0dad4abb678dc3d9116f536579e418176eedb8abb9105"
}
},
"args": {}
}
```
#### Example output
No output is expected for `cleanup_job`.
### `run_container_step`
The `run_container_step` command is called once for each container action in your job. {% data variables.product.prodname_actions %} assumes that you will do the following tasks in the `run_container_step` command:
- Pull or build the required container (or fail if you cannot).
- Run the container action and return the exit code of the container.
- Stream any step logs output to stdout and stderr.
- Cleanup the container after it executes.
#### Argumentos
- `image`: **Optional**. A string containing the docker image. Otherwise a dockerfile must be provided.
- `dockerfile`: **Optional**. A string containing the path to the dockerfile, otherwise an image must be provided.
- `entryPointArgs`: **Optional**. A list containing the entry point args.
- `entryPoint`: **Optional**. The container entry point to use if the default image entrypoint should be overwritten.
- `workingDirectory`: **Required**. A string containing the absolute path of the working directory.
- `createOptions`: **Optional**. The optional _create_ options specified in the YAML. For more information, see "[Example: Running a job within a container](/actions/using-jobs/running-jobs-in-a-container#example-running-a-job-within-a-container)."
- `environmentVariables`: **Optional**. Sets a map of key environment variables.
- `prependPath`: **Optional**. An array of additional paths to prepend to the `$PATH` variable.
- `userMountVolumes`: **Optional**. an array of user mount volumes set in the YAML. For more information, see "[Example: Running a job within a container](/actions/using-jobs/running-jobs-in-a-container#example-running-a-job-within-a-container)."
- `sourceVolumePath`: **Required**. The source path to the volume that will be mounted into the Docker container.
- `targetVolumePath`: **Required**. The target path to the volume that will be mounted into the Docker container.
- `readOnly`: **Required**. Determines whether or not the mount should be read-only.
- `systemMountVolumes`: **Required**. An array of mounts to mount into the container, using the same fields as above.
- `sourceVolumePath`: **Required**. The source path to the volume that will be mounted into the Docker container.
- `targetVolumePath`: **Required**. The target path to the volume that will be mounted into the Docker container.
- `readOnly`: **Required**. Determines whether or not the mount should be read-only.
- `registro` **Optional**. The Docker registry credentials for a private container registry.
- `username`: **Optional**. The username of the registry account.
- `password`: **Optional**. The password to the registry account.
- `serverUrl`: **Optional**. The registry URL.
- `portMappings`: **Optional**. A key value hash of the _source:target_ ports to map into the container.
#### Example input for image
If you're using a Docker image, you can specify the image name in the `"image":` parameter.
```json{:copy}
{
"command": "run_container_step",
"responseFile": null,
"state": {
"network": "example_network_53269bd575972817b43f7733536b200c",
"jobContainer": "82e8219701fe096a35941d869cf3d71af1d943b5d8bdd718857fb87ac3042480",
"serviceContainers": {
"redis": "60972d9aa486605e66b0dad4abb678dc3d9116f536579e418176eedb8abb9105"
}
},
"args": {
"image": "node:14.16",
"dockerfile": null,
"entryPointArgs": ["-f", "/dev/null"],
"entryPoint": "tail",
"workingDirectory": "/__w/octocat-test2/octocat-test2",
"createOptions": "--cpus 1",
"environmentVariables": {
"NODE_ENV": "development"
},
"prependPath": ["/foo/bar", "bar/foo"],
"userMountVolumes": [
{
"sourceVolumePath": "my_docker_volume",
"targetVolumePath": "/volume_mount",
"readOnly": false
}
],
"systemMountVolumes": [
{
"sourceVolumePath": "/home/octocat/git/runner/_layout/_work",
"targetVolumePath": "/__w",
"readOnly": false
},
{
"sourceVolumePath": "/home/octocat/git/runner/_layout/externals",
"targetVolumePath": "/__e",
"readOnly": true
},
{
"sourceVolumePath": "/home/octocat/git/runner/_layout/_work/_temp",
"targetVolumePath": "/__w/_temp",
"readOnly": false
},
{
"sourceVolumePath": "/home/octocat/git/runner/_layout/_work/_actions",
"targetVolumePath": "/__w/_actions",
"readOnly": false
},
{
"sourceVolumePath": "/home/octocat/git/runner/_layout/_work/_tool",
"targetVolumePath": "/__w/_tool",
"readOnly": false
},
{
"sourceVolumePath": "/home/octocat/git/runner/_layout/_work/_temp/_github_home",
"targetVolumePath": "/github/home",
"readOnly": false
},
{
"sourceVolumePath": "/home/octocat/git/runner/_layout/_work/_temp/_github_workflow",
"targetVolumePath": "/github/workflow",
"readOnly": false
}
],
"registry": null,
"portMappings": { "80": "801" }
}
}
```
#### Example input for Dockerfile
If your container is defined by a Dockerfile, this example demonstrates how to specify the path to a `Dockerfile` in your input, using the `"dockerfile":` parameter.
```json{:copy}
{
"command": "run_container_step",
"responseFile": null,
"state": {
"network": "example_network_53269bd575972817b43f7733536b200c",
"jobContainer": "82e8219701fe096a35941d869cf3d71af1d943b5d8bdd718857fb87ac3042480",
"services": {
"redis": "60972d9aa486605e66b0dad4abb678dc3d9116f536579e418176eedb8abb9105"
}
},
"args": {
"image": null,
"dockerfile": "/__w/_actions/foo/dockerfile",
"entryPointArgs": ["hello world"],
"entryPoint": "echo",
"workingDirectory": "/__w/octocat-test2/octocat-test2",
"createOptions": "--cpus 1",
"environmentVariables": {
"NODE_ENV": "development"
},
"prependPath": ["/foo/bar", "bar/foo"],
"userMountVolumes": [
{
"sourceVolumePath": "my_docker_volume",
"targetVolumePath": "/volume_mount",
"readOnly": false
}
],
"systemMountVolumes": [
{
"sourceVolumePath": "/home/octocat/git/runner/_layout/_work",
"targetVolumePath": "/__w",
"readOnly": false
},
{
"sourceVolumePath": "/home/octocat/git/runner/_layout/externals",
"targetVolumePath": "/__e",
"readOnly": true
},
{
"sourceVolumePath": "/home/octocat/git/runner/_layout/_work/_temp",
"targetVolumePath": "/__w/_temp",
"readOnly": false
},
{
"sourceVolumePath": "/home/octocat/git/runner/_layout/_work/_actions",
"targetVolumePath": "/__w/_actions",
"readOnly": false
},
{
"sourceVolumePath": "/home/octocat/git/runner/_layout/_work/_tool",
"targetVolumePath": "/__w/_tool",
"readOnly": false
},
{
"sourceVolumePath": "/home/octocat/git/runner/_layout/_work/_temp/_github_home",
"targetVolumePath": "/github/home",
"readOnly": false
},
{
"sourceVolumePath": "/home/octocat/git/runner/_layout/_work/_temp/_github_workflow",
"targetVolumePath": "/github/workflow",
"readOnly": false
}
],
"registry": null,
"portMappings": { "80": "801" }
}
}
```
#### Example output
No output is expected for `run_container_step`.
### `run_script_step`
{% data variables.product.prodname_actions %} assumes that you will do the following tasks:
- Invoke the provided script inside the job container and return the exit code.
- Stream any step log output to stdout and stderr.
#### Argumentos
- `entryPointArgs`: **Optional**. A list containing the entry point arguments.
- `entryPoint`: **Optional**. The container entry point to use if the default image entrypoint should be overwritten.
- `prependPath`: **Optional**. An array of additional paths to prepend to the `$PATH` variable.
- `workingDirectory`: **Required**. A string containing the absolute path of the working directory.
- `environmentVariables`: **Optional**. Sets a map of key environment variables.
#### Example input
```json{:copy}
{
"command": "run_script_step",
"responseFile": null,
"state": {
"network": "example_network_53269bd575972817b43f7733536b200c",
"jobContainer": "82e8219701fe096a35941d869cf3d71af1d943b5d8bdd718857fb87ac3042480",
"serviceContainers": {
"redis": "60972d9aa486605e66b0dad4abb678dc3d9116f536579e418176eedb8abb9105"
}
},
"args": {
"entryPointArgs": ["-e", "/runner/temp/example.sh"],
"entryPoint": "bash",
"environmentVariables": {
"NODE_ENV": "development"
},
"prependPath": ["/foo/bar", "bar/foo"],
"workingDirectory": "/__w/octocat-test2/octocat-test2"
}
}
```
#### Example output
No output is expected for `run_script_step`.
## Generating the customization script
{% data variables.product.prodname_dotcom %} has created an example repository that demonstrates how to generate customization scripts for Docker and Kubernetes.
{% note %}
**Note:** The resulting scripts are available for testing purposes, and you will need to determine whether they are appropriate for your requirements.
{% endnote %}
1. Clone the [actions/runner-container-hooks](https://github.com/actions/runner-container-hooks) repository to your self-hosted runner.
1. The `examples/` directory contains some existing customization commands, each with its own JSON file. You can review these examples and use them as a starting point for your own customization commands.
- `prepare_job.json`
- `run_script_step.json`
- `run_container_step.json`
1. Build the npm packages. These commands generate the `index.js` files inside `packages/docker/dist` and `packages/k8s/dist`.
```shell
npm install && npm run bootstrap && npm run build-all
```
When the resulting `index.js` is triggered by {% data variables.product.prodname_actions %}, it will run the customization commands defined in the JSON files. To trigger the `index.js`, you will need to add it your `ACTIONS_RUNNER_REQUIRE_JOB_CONTAINER` environment variable, as described in the next section.
## Triggering the customization script
The custom script must be located on the runner, but should not be stored in the self-hosted runner application directory. Os scripts são executados no contexto de segurança da conta de serviço que está executando o serviço do executor.
{% note %}
**Note**: The triggered script is processed synchronously, so it will block job execution while running.
{% endnote %}
The script is automatically executed when the runner has the following environment variable containing an absolute path to the script:
- `ACTIONS_RUNNER_CONTAINER_HOOK`: The script defined in this environment variable is triggered when a job has been assigned to a runner, but before the job starts running.
To set this environment variable, you can either add it to the operating system, or add it to a file named `.env` within the self-hosted runner application directory. For example, the following `.env` entry will have the runner automatically run the script at `/Users/octocat/runner/index.js` before each container-based job runs:
```bash
ACTIONS_RUNNER_CONTAINER_HOOK=/Users/octocat/runner/index.js
```
If you want to ensure that your job always runs inside a container, and subsequently always applies your container customizations, you can set the `ACTIONS_RUNNER_REQUIRE_JOB_CONTAINER` variable on the self hosted runner to `true`. This will fail jobs that do not specify a job container.
## Solução de Problemas
### Sem configuração de tempo limite
There is currently no timeout setting available for the script executed by `ACTIONS_RUNNER_CONTAINER_HOOK`. Como resultado, você pode considerar adicionar tempo limite de manipulação ao seu script.
### Revisando o log de execução do fluxo de trabalho
Para confirmar se seus scripts estão sendo executados, você pode revisar os logs para esse trabalho. Para obter mais informações sobre a verificação dos logs, consulte "[Visualizando os logs para diagnosticar as falhas](/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs#viewing-logs-to-diagnose-failures)".

1
translations/pt-BR/content/actions/hosting-your-own-runners/index.md
View File

@@ -20,6 +20,7 @@ children:
- /adding-self-hosted-runners
- /autoscaling-with-self-hosted-runners
- /running-scripts-before-or-after-a-job
- /customizing-the-containers-used-by-jobs
- /configuring-the-self-hosted-runner-application-as-a-service
- /using-a-proxy-server-with-self-hosted-runners
- /using-labels-with-self-hosted-runners

2
translations/pt-BR/content/code-security/security-overview/filtering-alerts-in-the-security-overview.md
View File

@@ -23,7 +23,7 @@ shortTitle: Filtrando alertas
## Sobre a filtragem da visão geral de segurança
Você pode usar filtros na visão geral de segurança para restringir seu foco baseado em uma série de fatores como, por exemplo, o nível de risco de alerta, tipo de alerta e habilitação do recurso. Existem filtros diferentes disponíveis, dependendo da visualização específica e da análise no nível da organização, da equipe ou do repositório.
Você pode usar filtros na visão geral de segurança para restringir seu foco baseado em uma série de fatores como, por exemplo, o nível de risco de alerta, tipo de alerta e habilitação do recurso. Different filters are available depending on the specific view and whether your analysis is at the organization, team or repository level.
## Filtrar por repositório

2
translations/pt-BR/content/developers/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps.md
View File

@@ -159,7 +159,7 @@ Como as permissões de nível de usuário são concedidas em uma base de usuári
## Solicitações de usuário para servidor
Embora a maior parte da interação da sua API deva ocorrer usando os tokens de acesso de servidor para servidor, certos pontos de extremidade permitem que você execute ações por meio da API usando um token de acesso do usuário. Seu aplicativo pode fazer as seguintes solicitações usando pontos de extremidade do [GraphQL v4]({% ifversion ghec %}/free-pro-team@latest{% endif %}/graphql) ou [REST v3](/rest).
Embora a maior parte da interação da sua API deva ocorrer usando os tokens de acesso de servidor para servidor, certos pontos de extremidade permitem que você execute ações por meio da API usando um token de acesso do usuário. Your app can make the following requests using [GraphQL]({% ifversion ghec %}/free-pro-team@latest{% endif %}/graphql) or [REST](/rest) endpoints.
### Pontos de extremidade compatíveis

2
translations/pt-BR/content/developers/apps/getting-started-with-apps/migrating-oauth-apps-to-github-apps.md
View File

@@ -53,7 +53,7 @@ Recomendamos que você reveja a lista de pontos finais de API de que você preci
### Projete para permanecer dentro dos limites de taxa da API
Os aplicativos GitHub usam [regras móveis para limites de taxa](/apps/building-github-apps/understanding-rate-limits-for-github-apps/), que podem aumentar com base no número de repositórios e usuários da organização. Um aplicativo do GitHub também pode usar [solicitações condicionais](/rest/overview/resources-in-the-rest-api#conditional-requests) ou consolidar solicitações usando [GraphQL API V4]({% ifversion ghec %}/free-pro-team@latest{% endif %}/graphql).
Os aplicativos GitHub usam [regras móveis para limites de taxa](/apps/building-github-apps/understanding-rate-limits-for-github-apps/), que podem aumentar com base no número de repositórios e usuários da organização. A GitHub App can also make use of [conditional requests](/rest/overview/resources-in-the-rest-api#conditional-requests) or consolidate requests by using the [GraphQL API]({% ifversion ghec %}/free-pro-team@latest{% endif %}/graphql).
### Cadastre um novo aplicativo GitHub

2
translations/pt-BR/content/developers/overview/about-githubs-apis.md
View File

@@ -14,7 +14,7 @@ topics:
- API
---
Existem duas versões estáveis da API do GitHub: a [API REST](/rest) e a [API do GraphQL]({% ifversion ghec %}/free-pro-team@latest{% endif %}/graphql). Ao usar a API REST, incentivamos que você a [solicite a v3 por meio do cabeçalho `Aceitar`](/v3/media/#request-specific-version). Para obter informações sobre como usar a API do GraphQL, consulte a [documentação da v4]({% ifversion ghec %}/free-pro-team@latest{% endif %}/graphql).
Existem duas versões estáveis da API do GitHub: a [API REST](/rest) e a [API do GraphQL]({% ifversion ghec %}/free-pro-team@latest{% endif %}/graphql).
## Versões obsoletas

2
translations/pt-BR/content/graphql/guides/using-global-node-ids.md
View File

@@ -12,7 +12,7 @@ topics:
- API
---
Você pode acessar a maioria dos objetos do GitHub (usuários, problemas, pull requests, etc.) usando a API REST ou a API do GraphQL. Você pode encontrar o **ID do nó global** de muitos objetos de dentro da API REST e usar esses IDs nas operações do GraphQL. Para obter mais informações, consulte "[Pré-visualizações dos IDs do nó da API do GraphQL v4 nos recursos da API REST v3](https://developer.github.com/changes/2017-12-19-graphql-node-id/)".
Você pode acessar a maioria dos objetos do GitHub (usuários, problemas, pull requests, etc.) usando a API REST ou a API do GraphQL. Você pode encontrar o **ID do nó global** de muitos objetos de dentro da API REST e usar esses IDs nas operações do GraphQL. For more information, see "[Preview GraphQL API Node IDs in REST API resources](https://developer.github.com/changes/2017-12-19-graphql-node-id/)."
{% note %}

18
translations/pt-BR/content/graphql/overview/resource-limitations.md
View File

@@ -14,7 +14,7 @@ topics:
## Limite de nó
Para passar a validação do [esquema](/graphql/guides/introduction-to-graphql#schema), todas as [chamadas ](/graphql/guides/forming-calls-with-graphql) da API v4 do GraphQL devem atender a esses padrões:
To pass [schema](/graphql/guides/introduction-to-graphql#schema) validation, all GraphQL API [calls](/graphql/guides/forming-calls-with-graphql) must meet these standards:
* Os clientes devem fornecer um `primeiro` ou `último` argumento [conexão](/graphql/guides/introduction-to-graphql#connection).
* Os valores de `primeiro` e `último` devem ser entre 1 e 100.
@@ -130,30 +130,30 @@ Estes dois exemplos mostram como calcular os nós totais em uma chamada.
## Limite de taxa
O [limite de taxas](/rest/overview/resources-in-the-rest-api#rate-limiting) do GraphQL API v4 é diferente dos limites de taxa do REST API v3.
The GraphQL API limit is different from the REST API's [rate limits](/rest/overview/resources-in-the-rest-api#rate-limiting).
Por que os limites de taxa de API são diferentes? Com o [GraphQL](/graphql), uma chamada do GraphQL pode substituir [várias chamadas de REST](/graphql/guides/migrating-from-rest-to-graphql). Uma chamada única e complexa do GraphQL poderia ser o equivalente a milhares de solicitações de REST. Embora uma única chamada GraphQL fique bem abaixo do limite de taxa de API REST, a consulta pode ser muito cara para os servidores do GitHub calcularem.
Para representar com precisão o custo de servidor de uma consulta, a API v4 do GraphQL calcula a **pontuação de um limite de taxa** de uma chamada com base em uma escala normalizada de pontos. Os fatores de pontuação de uma consulta no primeiro e último argumentos em uma conexão principal e suas conexões auxiliares.
To accurately represent the server cost of a query, the GraphQL API calculates a call's **rate limit score** based on a normalized scale of points. Os fatores de pontuação de uma consulta no primeiro e último argumentos em uma conexão principal e suas conexões auxiliares.
* A fórmula usa argumentos `primeiros` e `último` na conexão principal e nas conexões secundárias para pré-calcular o potencial de carga nos sistemas do GitHub, como MySQL, ElasticSearch e Git.
* Cada nova conexão tem o seu valor próprio de pontos. Os pontos são combinados com outros pontos da chamada para uma pontuação de limite de taxa geral.
O limite de taxa de câmbio da API v4 do GraphQL é **5.000 pontos por hora**.
The GraphQL API rate limit is **5,000 points per hour**.
Observe que 5.000 pontos por hora não é o mesmo que 5.000 chamadas por hora: a API v4 do GraphQL e a API v3 de REST usam diferentes limites de taxa.
Note that 5,000 points per hour is not the same as 5,000 calls per hour: the GraphQL API and REST API use different rate limits.
{% note %}
**Observação**: A fórmula atual e o limite de taxa estão sujeitos a alterações à medida que observamos como os desenvolvedores usam a API v4 do GraphQL.
**Note**: The current formula and rate limit are subject to change as we observe how developers use the GraphQL API.
{% endnote %}
### Retornar o status de limite da chamada
Com a API REST v3, você pode verificar o status do limite de taxa [inspecionando](/rest/overview/resources-in-the-rest-api#rate-limiting) os cabeçalhos HTTP retornados.
With the REST API, you can check the rate limit status by [inspecting](/rest/overview/resources-in-the-rest-api#rate-limiting) the returned HTTP headers.
Com o GraphQL API v4, você pode verificar o status do limite de taxa consultando campos no objeto `rateLimit`:
With the GraphQL API, you can check the rate limit status by querying fields on the `rateLimit` object:
```graphql
query {
@@ -186,7 +186,7 @@ Consultar o objeto `rateLimit` retorna a pontuação de uma chamada, mas executa
{% note %}
**Observação**: O custo mínimo de uma chamada para a API v4 do GraphQL é **1**, o que representa uma única solicitação.
**Note**: The minimum cost of a call to the GraphQL API is **1**, representing a single request.
{% endnote %}

2
translations/pt-BR/content/rest/overview/resources-in-the-rest-api.md
View File

@@ -24,7 +24,7 @@ Por padrão, todas as solicitações para `{% data variables.product.api_url_cod
{% ifversion fpt or ghec %}
Para obter informações sobre a API do GraphQL do GitHub, consulte a [documentação v4]({% ifversion ghec %}/free-pro-team@latest{% endif %}/graphql). Para obter informações sobre migração para o GraphQL, consulte "[Fazendo a migração do REST]({% ifversion ghec%}/free-pro-team@latest{% endif %}/graphql/guides/migrating-from-rest-to-graphql)".
For information about GitHub's GraphQL API, see the [documentation]({% ifversion ghec %}/free-pro-team@latest{% endif %}/graphql). Para obter informações sobre migração para o GraphQL, consulte "[Fazendo a migração do REST]({% ifversion ghec%}/free-pro-team@latest{% endif %}/graphql/guides/migrating-from-rest-to-graphql)".
{% endif %}

7
translations/pt-BR/data/features/container-hooks.yml Normal file
View File

@@ -0,0 +1,7 @@
---
#Reference: #7070
#Actions Runner Container Hooks
versions:
fpt: '*'
ghec: '*'
ghae: 'issue-7070'

15
translations/pt-BR/data/reusables/actions/jobs/section-running-jobs-in-a-container.md
View File

@@ -4,9 +4,14 @@ Se você não definir um `container`, todas as etapas serão executadas diretame
### Exemplo: Executar um trabalho dentro de um contêiner
```yaml
```yaml{:copy}
name: CI
on:
push:
branches: [ main ]
jobs:
my_job:
container-test-job:
runs-on: ubuntu-latest
container:
image: node:14.16
env:
@@ -16,12 +21,16 @@ jobs:
volumes:
- my_docker_volume:/volume_mount
options: --cpus 1
steps:
- name: Check for dockerenv file
run: (ls /.dockerenv && echo Found dockerenv) || (echo No dockerenv)
```
Ao especificar somente uma imagem de contêiner, você pode omitir a palavra-chave `image`.
```yaml
jobs:
my_job:
container-test-job:
runs-on: ubuntu-latest
container: node:14.16
```