1
0
mirror of synced 2026-01-08 03:01:54 -05:00

Merge pull request #17829 from github/repo-sync

repo sync
This commit is contained in:
Octomerger Bot
2022-05-13 15:27:03 -05:00
committed by GitHub
19 changed files with 146 additions and 29 deletions

View File

@@ -92,12 +92,12 @@ jobs:
run: |
sed 's|#{IMAGE}#|${{ env.DOCKER_IMAGE }}|g' docker-compose.prod.tmpl.yaml > docker-compose.prod.yaml
- name: 'Apply updated docker-compose.prod.yaml config to staging slot'
- name: 'Apply updated docker-compose.prod.yaml config to canary slot'
run: |
az webapp config container set --multicontainer-config-type COMPOSE --multicontainer-config-file docker-compose.prod.yaml --slot staging -n ghdocs-prod -g docs-prod
az webapp config container set --multicontainer-config-type COMPOSE --multicontainer-config-file docker-compose.prod.yaml --slot canary -n ghdocs-prod -g docs-prod
# Watch staging slot instances to see when all the instances are ready
- name: Check that staging slot is ready
# Watch canary slot instances to see when all the instances are ready
- name: Check that canary slot is ready
uses: actions/github-script@2b34a689ec86a68d8ab9478298f91d5401337b7d
env:
CHECK_INTERVAL: 10000
@@ -117,7 +117,7 @@ jobs:
let hasStopped = false
const waitDuration = parseInt(process.env.CHECK_INTERVAL, 10) || 10000
async function doCheck() {
const states = getStatesForSlot('staging')
const states = getStatesForSlot('canary')
console.log(`Instance states:`, states)
// We must wait until at-least 1 instance has STOPPED to know we're looking at the "next" deployment and not the "previous" one
@@ -138,10 +138,10 @@ jobs:
doCheck()
# TODO - make a request to verify the staging app version aligns with *this* github action workflow commit sha
- name: 'Swap staging slot to production'
# TODO - make a request to verify the canary app version aligns with *this* github action workflow commit sha
- name: 'Swap canary slot to production'
run: |
az webapp deployment slot swap --slot staging --target-slot production -n ghdocs-prod -g docs-prod
az webapp deployment slot swap --slot canary --target-slot production -n ghdocs-prod -g docs-prod
- name: Purge Fastly edge cache
env:

View File

@@ -12,6 +12,12 @@ shortTitle: Omitir ejecuciones de flujo de trabajo
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% note %}
**Note:** If a workflow is skipped due to [path filtering](/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore), [branch filtering](/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore) or a commit message (see below), then checks associated with that workflow will remain in a "Pending" state. A pull request that requires those checks to be successful will be blocked from merging.
{% endnote %}
Los flujos de trabajo que comúnmente se activarían utilizando `on: push` o `on: pull_request`, no se activarán si agregas cualquiera de las siguientes secuencias al mensaje de confirmación en una subida o a la confirmación PRINCIPAL (HEAD) de una solicitud de cambios:
* `[skip ci]`

View File

@@ -201,6 +201,14 @@ El mismo principio que se describió anteriormente para utilizar acciones de ter
{% data reusables.actions.outside-collaborators-internal-actions %} Para obtener más información, consulta la sección "[Compartir acciones y flujos de trabajo con tu empresa](/actions/creating-actions/sharing-actions-and-workflows-with-your-enterprise)".
{% endif %}
{% if allow-actions-to-approve-pr %}
## Preventing {% data variables.product.prodname_actions %} from {% if allow-actions-to-approve-pr-with-ent-repo %}creating or {% endif %}approving pull requests
{% data reusables.actions.workflow-pr-approval-permissions-intro %} Allowing workflows, or any other automation, to {% if allow-actions-to-approve-pr-with-ent-repo %}create or {% endif %}approve pull requests could be a security risk if the pull request is merged without proper oversight.
For more information on how to configure this setting, see {% if allow-actions-to-approve-pr-with-ent-repo %}{% ifversion ghes or ghec or ghae %}"[Enforcing policies for {% data variables.product.prodname_actions %} in your enterprise](/enterprise-cloud@latest/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#preventing-github-actions-from-creating-or-approving-pull-requests)",{% endif %}{% endif %} "[Disabling or limiting {% data variables.product.prodname_actions %} for your organization](/github/setting-up-and-managing-organizations-and-teams/disabling-or-limiting-github-actions-for-your-organization#preventing-github-actions-from-{% if allow-actions-to-approve-pr-with-ent-repo %}creating-or-{% endif %}approving-pull-requests)"{% if allow-actions-to-approve-pr-with-ent-repo %}, and "[Managing {% data variables.product.prodname_actions %} settings for a repository](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#preventing-github-actions-from-creating-or-approving-pull-requests)"{% endif %}.
{% endif %}
## Utilizar las tarjetas de puntuación para asegurar los flujos de trabajo
[Las tarjetas de puntuación](https://github.com/ossf/scorecard) son una herramienta de seguridad automatizada que resalta las prácticas riesgosas en la cadena de suministro. Puedes utilizar la [Acción de tarjetas de puntuación](https://github.com/marketplace/actions/ossf-scorecard-action) y el [flujo de trabajo inicial](https://github.com/actions/starter-workflows) para seguir las mejores prácticas de seguridad. Una vez que se configure, la acción de tarjetas de puntuación se ejecutará automáticamente en los cambios de repositorio y alertará a los desarrolladores sobre las prácticas riesgosas en la cadena de suministro utilizando la experiencia de escaneo en el código integrado. El proyecto de tarjetas de puntuación ejecuta varias verificaciones, incluyendo las de ataques de inyección de scripts, permisos de tokens y acciones fijadas.

View File

@@ -15,4 +15,14 @@ miniTocMaxHeadingLevel: 4
## Resumen
{% note %}
**Note:** A job that is skipped will report its status as "Success". It will not prevent a pull request from merging, even if it is a required check.
{% endnote %}
{% data reusables.actions.jobs.section-using-conditions-to-control-job-execution %}
You would see the following status on a skipped job:
![Skipped-required-run-details](/assets/images/help/repository/skipped-required-run-details.png)

View File

@@ -1,6 +1,6 @@
---
title: Instalar el servidor de GitHub Enterprise en Azure
intro: 'Para instalar {% data variables.product.prodname_ghe_server %} en Azure, debes implementar en una instancia de serie DS y usar almacenamiento Premium-LRS.'
intro: 'To install {% data variables.product.prodname_ghe_server %} on Azure, you must deploy onto a memory-optimized instance that supports premium storage.'
redirect_from:
- /enterprise/admin/guides/installation/installing-github-enterprise-on-azure
- /enterprise/admin/installation/installing-github-enterprise-server-on-azure
@@ -30,7 +30,8 @@ Puedes implementar {% data variables.product.prodname_ghe_server %} en Azure mun
## Determinar el tipo de máquina virtual
Antes de iniciar {% data variables.product.product_location %} en Azure, deberás determinar el tipo de máquina que mejor se adapte a las necesidades de tu organización. Para revisar los requisitos mínimos para {% data variables.product.product_name %}, consulta la sección "[Requisitos mínimos](#minimum-requirements)".
Antes de iniciar {% data variables.product.product_location %} en Azure, deberás determinar el tipo de máquina que mejor se adapte a las necesidades de tu organización. For more information about memory optimized machines, see "[Memory optimized virtual machine sizes](https://docs.microsoft.com/en-gb/azure/virtual-machines/sizes-memory)" in the Microsoft Azure documentation. To review the minimum resource requirements for {% data variables.product.product_name %}, see "[Minimum requirements](#minimum-requirements)."
{% data reusables.enterprise_installation.warning-on-scaling %}

View File

@@ -121,16 +121,40 @@ Si se habilita una política para una empresa, esta puede inhabilitarse selectiv
{% data reusables.actions.workflow-permissions-intro %}
Puedes configurar los permisos predeterminados para del `GITHUB_TOKEN` en la configuración de tu empresa, organización o repositorio. Si eliges la opción restringida como lo predeterminado en la configuración de tu empresa, esto previene que puedas elegir más configuraciones permisivas en la configuración de tu organización o repositorio.
Puedes configurar los permisos predeterminados para del `GITHUB_TOKEN` en la configuración de tu empresa, organización o repositorio. If you choose a restricted option as the default in your enterprise settings, this prevents the more permissive setting being chosen in the organization or repository settings.
{% data reusables.actions.workflow-permissions-modifying %}
### Configuring the default `GITHUB_TOKEN` permissions
{% if allow-actions-to-approve-pr-with-ent-repo %}
By default, when you create a new enterprise, `GITHUB_TOKEN` only has read access for the `contents` scope.
{% endif %}
{% data reusables.enterprise-accounts.access-enterprise %}
{% data reusables.enterprise-accounts.policies-tab %}
{% data reusables.enterprise-accounts.actions-tab %}
1. Debajo de **Permisos del flujo de trabajo**, elige si quieres que el `GITHUB_TOKEN` tenga permisos de lectura y escritura para todos los alcances o solo acceso de lectura para el alcance `contents`. ![Configurar los permisos del GITHUB_TOKEN para esta empresa](/assets/images/help/settings/actions-workflow-permissions-enterprise.png)
1. Under "Workflow permissions", choose whether you want the `GITHUB_TOKEN` to have read and write access for all scopes, or just read access for the `contents` scope.
![Configurar los permisos del GITHUB_TOKEN para esta empresa](/assets/images/help/settings/actions-workflow-permissions-enterprise{% if allow-actions-to-approve-pr-with-ent-repo %}-with-pr-approval{% endif %}.png)
1. Da clic en **Guardar** para aplicar la configuración.
{% if allow-actions-to-approve-pr-with-ent-repo %}
### Preventing {% data variables.product.prodname_actions %} from creating or approving pull requests
{% data reusables.actions.workflow-pr-approval-permissions-intro %}
By default, when you create a new enterprise, workflows are not allowed to create or approve pull requests.
{% data reusables.enterprise-accounts.access-enterprise %}
{% data reusables.enterprise-accounts.policies-tab %}
{% data reusables.enterprise-accounts.actions-tab %}
1. Under "Workflow permissions", use the **Allow GitHub Actions to create and approve pull requests** setting to configure whether `GITHUB_TOKEN` can create and approve pull requests.
![Configurar los permisos del GITHUB_TOKEN para esta empresa](/assets/images/help/settings/actions-workflow-permissions-enterprise-with-pr-approval.png)
1. Da clic en **Guardar** para aplicar la configuración.
{% endif %}
{% endif %}
{% if actions-cache-policy-apis %}

View File

@@ -452,9 +452,9 @@ jobs:
### Habilita la fusión automática en una solicitud de cambios
Si quieres fusionar tus solicitudes de cambios automáticamente, puedes utilizar la funcionalidad de fusión automática de {% data variables.product.prodname_dotcom %}. Esto habilita a la solicitud de cambios para que se fusione cuando se cumpla con todas las pruebas y aprobaciones requeridas. For more information on auto-merge, see "[Automatically merging a pull request](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request)."
If you want to allow maintainers to mark certain pull requests for auto-merge, you can use {% data variables.product.prodname_dotcom %}'s auto-merge functionality. Esto habilita a la solicitud de cambios para que se fusione cuando se cumpla con todas las pruebas y aprobaciones requeridas. For more information on auto-merge, see "[Automatically merging a pull request](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request)."
Aquí tienes un ejemplo de cómo habilitar la fusión automática para todas las actualizaciones de parche en `my-dependency`:
You can instead use {% data variables.product.prodname_actions %} and the {% data variables.product.prodname_cli %}. Here is an example that auto merges all patch updates to `my-dependency`:
{% ifversion ghes = 3.3 %}

View File

@@ -44,7 +44,7 @@ Las wikis son parte de los repositorios Gift, de manera que puedes hacer cambios
### Clonar wikis en tu computadora
Cada wiki brinda una manera sencilla de clonar sus contenidos en tu computadora. Puedes clonar el repositorio a tu computadora con la URL proporcionada:
Cada wiki brinda una manera sencilla de clonar sus contenidos en tu computadora. Once you've created an initial page on {% data variables.product.product_name %}, you can clone the repository to your computer with the provided URL:
```shell
$ git clone https://github.com/<em>YOUR_USERNAME</em>/<em>YOUR_REPOSITORY</em>.wiki.git

View File

@@ -103,16 +103,40 @@ Puedes configurar este comportamiento de una organización utilizando los siguie
{% data reusables.actions.workflow-permissions-intro %}
Puedes configurar los permisos predeterminados para el `GITHUB_TOKEN` en la configuración de tu organización o tus repositorios. Si eliges la opción restringida como la predeterminada en tu configuración de organización, la misma opción se auto-seleccionará en la configuración de los repositorios dentro de dicha organización y se inhabilitará la opción permisiva. Si tu organización le pertenece a una cuenta {% data variables.product.prodname_enterprise %} y la configuración predeterminada más restringida se seleccionó en la configuración de dicha empresa, no podrás elegir la opción predeterminada permisiva en la configuración de tu organización.
Puedes configurar los permisos predeterminados para el `GITHUB_TOKEN` en la configuración de tu organización o tus repositorios. If you select a restrictive option as the default in your organization settings, the same option is selected in the settings for repositories within your organization, and the permissive option is disabled. If your organization belongs to a {% data variables.product.prodname_enterprise %} account and a more restrictive default has been selected in the enterprise settings, you won't be able to select the more permissive default in your organization settings.
{% data reusables.actions.workflow-permissions-modifying %}
### Configuring the default `GITHUB_TOKEN` permissions
{% if allow-actions-to-approve-pr-with-ent-repo %}
By default, when you create a new organization, `GITHUB_TOKEN` only has read access for the `contents` scope.
{% endif %}
{% data reusables.profile.access_profile %}
{% data reusables.profile.access_org %}
{% data reusables.profile.org_settings %}
{% data reusables.organizations.settings-sidebar-actions-general %}
1. Debajo de **Permisos del flujo de trabajo**, elige si quieres que el `GITHUB_TOKEN` tenga permisos de lectura y escritura para todos los alcances o solo acceso de lectura para el alcance `contents`. ![Configurar los permisos del GITHUB_TOKEN para esta organización](/assets/images/help/settings/actions-workflow-permissions-organization.png)
1. Under "Workflow permissions", choose whether you want the `GITHUB_TOKEN` to have read and write access for all scopes, or just read access for the `contents` scope.
![Configurar los permisos del GITHUB_TOKEN para esta organización](/assets/images/help/settings/actions-workflow-permissions-organization{% if allow-actions-to-approve-pr %}-with-pr-{% if allow-actions-to-approve-pr-with-ent-repo %}creation-{% endif %}approval{% endif %}.png)
1. Da clic en **Guardar** para aplicar la configuración.
{% if allow-actions-to-approve-pr %}
### Preventing {% data variables.product.prodname_actions %} from {% if allow-actions-to-approve-pr-with-ent-repo %}creating or {% endif %}approving pull requests
{% data reusables.actions.workflow-pr-approval-permissions-intro %}
By default, when you create a new organization, workflows are not allowed to {% if allow-actions-to-approve-pr-with-ent-repo %}create or {% endif %}approve pull requests.
{% data reusables.profile.access_profile %}
{% data reusables.profile.access_org %}
{% data reusables.profile.org_settings %}
{% data reusables.organizations.settings-sidebar-actions-general %}
1. Under "Workflow permissions", use the **Allow GitHub Actions to {% if allow-actions-to-approve-pr-with-ent-repo %}create and {% endif %}approve pull requests** setting to configure whether `GITHUB_TOKEN` can {% if allow-actions-to-approve-pr-with-ent-repo %}create and {% endif %}approve pull requests.
![Set GITHUB_TOKEN pull request approval permission for this organization](/assets/images/help/settings/actions-workflow-permissions-organization{% if allow-actions-to-approve-pr %}-with-pr-{% if allow-actions-to-approve-pr-with-ent-repo %}creation-{% endif %}approval{% endif %}.png)
1. Da clic en **Guardar** para aplicar la configuración.
{% endif %}
{% endif %}

View File

@@ -48,13 +48,17 @@ Algunas veces, los resultados de las verificaciones de estado para la confirmaci
## Se salta el manejo pero se requieren las verificaciones
Algunas veces, se salta una verificación de estado requerida en las solicitudes de cambios debido al filtrado de rutas. Por ejemplo, una prueba de Node.JS podría saltarse en una solicitud de cambios que solo arregla un error de dedo en tu archivo README y no hace cambios a los archivos de JavaScript y TypeScript en el directorio de `scripts`.
{% note %}
Si esta verificación es requerida y se salta, entonces el estado de verificación se mostrará como pendiente, dado que es requerida. En esta situación no podrás fusionar la solicitud de cambios.
**Note:** If a workflow is skipped due to [path filtering](/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore), [branch filtering](/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore) or a [commit message](/actions/managing-workflow-runs/skipping-workflow-runs), then checks associated with that workflow will remain in a "Pending" state. A pull request that requires those checks to be successful will be blocked from merging.
If a job in a workflow is skipped due to a conditional, it will report its status as "Success". For more information see [Skipping workflow runs](/actions/managing-workflow-runs/skipping-workflow-runs) and [Using conditions to control job execution](/actions/using-jobs/using-conditions-to-control-job-execution).
{% endnote %}
### Ejemplo
En este ejemplo, tienes un flujo de trabajo que se requiere para pasar.
The following example shows a workflow that requires a "Successful" completion status for the `build` job, but the workflow will be skipped if the pull request does not change any files in the `scripts` directory.
```yaml
name: ci
@@ -62,7 +66,6 @@ on:
pull_request:
paths:
- 'scripts/**'
- 'middleware/**'
jobs:
build:
runs-on: ubuntu-latest
@@ -81,7 +84,7 @@ jobs:
- run: npm test
```
Si alguien emite una solicitud de cambios que cambie un archivo de lenguaje de marcado en la raíz del repositorio, entonces el flujo de trabajo anterior no se ejecutará para nada debido al filtrado de ruta. Como resultado, no podrás fusionar la solicitud de cambios. Verías el siguiente estado en la solicitud de cambios:
Due to [path filtering](/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore), a pull request that only changes a file in the root of the repository will not trigger this workflow and is blocked from merging. Verías el siguiente estado en la solicitud de cambios:
![Verificación requerida omitida, pero mostrada como pendiente](/assets/images/help/repository/PR-required-check-skipped.png)

View File

@@ -106,20 +106,40 @@ Si se inhabilita una política para una {% ifversion ghec or ghae or ghes %}empr
{% data reusables.actions.workflow-permissions-intro %}
Los permisos predeterminados también pueden configurarse en los ajustes de la organización. Si el predeterminado más restringido se seleccionó en la configuración de la organización, la misma opción se autoselecciona en tu configuración de repositorio y la opción permisiva se inhabilita.
Los permisos predeterminados también pueden configurarse en los ajustes de la organización. If your repository belongs to an organization and a more restrictive default has been selected in the organization settings, the same option is selected in your repository settings and the permissive option is disabled.
{% data reusables.actions.workflow-permissions-modifying %}
### Configuring the default `GITHUB_TOKEN` permissions
{% if allow-actions-to-approve-pr-with-ent-repo %}
By default, when you create a new repository in your personal account, `GITHUB_TOKEN` only has read access for the `contents` scope. If you create a new repository in an organization, the setting is inherited from what is configured in the organization settings.
{% endif %}
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-settings %}
{% data reusables.repositories.settings-sidebar-actions-general %}
1. Debajo de **Permisos del flujo de trabajo**, elige si quieres que el `GITHUB_TOKEN` tenga permisos de lectura y escritura para todos los alcances o solo acceso de lectura para el alcance `contents`.
1. Under "Workflow permissions", choose whether you want the `GITHUB_TOKEN` to have read and write access for all scopes, or just read access for the `contents` scope.
![Configurar los permisos del GITHUB_TOKEN para este repositorio](/assets/images/help/settings/actions-workflow-permissions-repository.png)
![Configurar los permisos del GITHUB_TOKEN para este repositorio](/assets/images/help/settings/actions-workflow-permissions-repository{% if allow-actions-to-approve-pr-with-ent-repo %}-with-pr-approval{% endif %}.png)
1. Da clic en **Guardar** para aplicar la configuración.
{% if allow-actions-to-approve-pr-with-ent-repo %}
### Preventing {% data variables.product.prodname_actions %} from creating or approving pull requests
{% data reusables.actions.workflow-pr-approval-permissions-intro %}
By default, when you create a new repository in your personal account, workflows are not allowed to create or approve pull requests. If you create a new repository in an organization, the setting is inherited from what is configured in the organization settings.
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-settings %}
{% data reusables.repositories.settings-sidebar-actions-general %}
1. Under "Workflow permissions", use the **Allow GitHub Actions to create and approve pull requests** setting to configure whether `GITHUB_TOKEN` can create and approve pull requests.
![Configurar los permisos del GITHUB_TOKEN para este repositorio](/assets/images/help/settings/actions-workflow-permissions-repository-with-pr-approval.png)
1. Da clic en **Guardar** para aplicar la configuración.
{% endif %}
{% endif %}
{% ifversion ghes > 3.3 or ghae-issue-4757 or ghec %}

View File

@@ -0,0 +1,8 @@
---
#Reference: #6926.
#Versioning for enterprise/repository policy settings for workflow PR creation or approval permission. This is only the enterprise and repo settings! For the previous separate ship for the org setting (that only overed approvals), see the allow-actions-to-approve-pr flag.
versions:
fpt: '*'
ghec: '*'
ghes: '>=3.6'
ghae: 'issue-6926'

View File

@@ -0,0 +1,8 @@
---
#Reference: #6926.
#Versioning for org policy settings for workflow PR approval permission. This is only org setting! For the later separate ship for the enterprise and repo setting, see the allow-actions-to-approve-pr-with-ent-repo flag.
versions:
fpt: '*'
ghec: '*'
ghes: '>=3.5'
ghae: 'issue-6926'

View File

@@ -18,7 +18,7 @@ sections:
- "Dependabot version and security updates are now generally available in GitHub Enterprise Server 3.5. All the popular ecosystems and features that work on GitHub.com repositories now can be set up on your GitHub Enterprise Server instance. Dependabot on GitHub Enterprise Server requires GitHub Actions and a pool of self-hosted Dependabot runners, GitHub Connect enabled, and Dependabot enabled by an admin.\n\nFollowing on from the public beta release, we will be supporting the use of GitHub Actions runners hosted on a Kubernetes setup.\n\nFor more information, see \"[Setting up Dependabot updates](https://docs.github.com/en/enterprise-server@3.5/admin/github-actions/enabling-github-actions-for-github-enterprise-server/setting-up-dependabot-updates).\"\n"
- heading: 'Server Statistics in public beta'
notes:
- "You can now analyze how your team works, understand the value you get from GitHub Enterprise Server, and help us improve our products by reviewing your instance's usage data and sharing this aggregate data with GitHub. You can use your own tools to analyze your usage over time by downloading your data in a CSV or JSON file or by accessing it using the REST API. To see the list of aggregate metrics collected, see \"[About Server Statistics](/admin/monitoring-activity-in-your-enterprise/analyzing-how-your-team-works-with-server-statistics/about-server-statistics#server-statistics-data-collected).\" **Server Statistics data includes no personal data nor GitHub content, such as code, issues, comments, or pull requests content. For a better understanding of how we store and secure Server Statistics data, see \"[GitHub Security](https://github.com/security).\"** For more information about Server Statistics, see \"[Analyzing how your team works with Server Statistics](/admin/monitoring-activity-in-your-enterprise/analyzing-how-your-team-works-with-server-statistics).\" This feature is available in public beta.\n"
- "You can now analyze how your team works, understand the value you get from GitHub Enterprise Server, and help us improve our products by reviewing your instance's usage data and sharing this aggregate data with GitHub. You can use your own tools to analyze your usage over time by downloading your data in a CSV or JSON file or by accessing it using the REST API. To see the list of aggregate metrics collected, see \"[About Server Statistics](/admin/monitoring-activity-in-your-enterprise/analyzing-how-your-team-works-with-server-statistics/about-server-statistics#server-statistics-data-collected).\" Server Statistics data includes no personal data nor GitHub content, such as code, issues, comments, or pull requests content. For a better understanding of how we store and secure Server Statistics data, see \"[GitHub Security](https://github.com/security).\" For more information about Server Statistics, see \"[Analyzing how your team works with Server Statistics](/admin/monitoring-activity-in-your-enterprise/analyzing-how-your-team-works-with-server-statistics).\" This feature is available in public beta.\n"
- heading: 'GitHub Actions rate limiting is now configurable'
notes:
- "Site administrators can now enable and configure a rate limit for GitHub Actions. By default, the rate limit is disabled. When workflow jobs cannot immediately be assigned to an available runner, they will wait in a queue until a runner is available. However, if GitHub Actions experiences a sustained high load, the queue can back up faster than it can drain and the performance of the GitHub Enterprise Server instance may degrade. To avoid this, an administrator can configure a rate limit. When the rate limit is exceeded, additional workflow runs will fail immediately rather than being put in the queue. Once the rate has stabilized below the threshold, new runs can be queued again. For more information, see \"[Configuring rate limits](/admin/configuration/configuring-your-enterprise/configuring-rate-limits#configuring-rate-limits-for-github-actions).\"\n"

View File

@@ -1 +1 @@
Puedes configurar los permisos predeterminados que se otorgaron al `GITHUB_TOKEN`. Para obtener más información sobre el `GITHUB_TOKEN`, consulta ""[Automatic token authentication](/actions/security-guides/automatic-token-authentication)". Puedes elegir entre un conjunto restringido de permisos o una configuración permisiva como lo predeterminado.
Puedes configurar los permisos predeterminados que se otorgaron al `GITHUB_TOKEN`. Para obtener más información sobre el `GITHUB_TOKEN`, consulta ""[Automatic token authentication](/actions/security-guides/automatic-token-authentication)". You can choose a restricted set of permissions as the default, or apply permissive settings.

View File

@@ -0,0 +1 @@
You can choose to allow or prevent {% data variables.product.prodname_actions %} workflows from{% if allow-actions-to-approve-pr-with-ent-repo %} creating or{% endif %} approving pull requests.

View File

@@ -51,7 +51,7 @@ El orden en que defines los patrones importa.
- Un patrón negativo de coincidencia (con prefijo `!`) luego de una coincidencia positiva excluirá la ref de Git.
- Un patrón positivo de coincidencia luego de una coincidencia negativa volverá a incluir la ref de Git.
El siguiente flujo de trabajo se ejecutará en eventos de `pull_request` para las solicitudes de cambio que apunten a `releases/10` o `releases/beta/mona`, pero para aquellas que empaten con `releases/10-alpha` o `releases/beta/3-alpha`, ya que el patrón negativo `!releases/**-alpha` sigue al patrón positivo.
The following workflow will run on `pull_request` events for pull requests that target `releases/10` or `releases/beta/mona`, but not for pull requests that target `releases/10-alpha` or `releases/beta/3-alpha` because the negative pattern `!releases/**-alpha` follows the positive pattern.
```yaml
on:

View File

@@ -20,7 +20,7 @@ on:
{% note %}
**Note:** If a workflow is skipped due to path filtering, but the workflow is set as a required check, then the check will remain as "Pending". To work around this, you can create a corresponding workflow with the same name that always passes whenever the original workflow is skipped because of path filtering. For more information, see "[Handling skipped but required checks](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks#handling-skipped-but-required-checks)."
**Note:** If a workflow is skipped due to [path filtering](/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore), [branch filtering](/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore) or a [commit message](/actions/managing-workflow-runs/skipping-workflow-runs), then checks associated with that workflow will remain in a "Pending" state. A pull request that requires those checks to be successful will be blocked from merging. For more information, see "[Handling skipped but required checks](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks#handling-skipped-but-required-checks)."
{% endnote %}

View File

@@ -22,6 +22,10 @@
| Sistemas Contribuidos | Credenciales de los sistemas contribuidos |
| Databricks | Token de Acceso de Databricks |
| Datadog | Clave de API de Datadog |
| DigitalOcean | DigitalOcean Personal Access Token |
| DigitalOcean | DigitalOcean OAuth Token |
| DigitalOcean | DigitalOcean Refresh Token |
| DigitalOcean | DigitalOcean System Token |
| Discord | Token de Bot de Discord |
| Doppler | Token Personal de Doppler |
| Doppler | Token de Servicio de Doppler |