@@ -46,17 +46,10 @@ You can send an invitation to collaborate in your repository directly to someone
|
||||
1. Ask for the username of the person you're inviting as a collaborator.{% ifversion fpt or ghec %} If they don't have a username yet, they can sign up for {% data variables.product.prodname_dotcom %}. For more information, see "[AUTOTITLE](/get-started/signing-up-for-github/signing-up-for-a-new-github-account)."{% endif %}
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4%}
|
||||
1. In the "Access" section of the sidebar, click **{% octicon "people" aria-hidden="true" %} Collaborators**.
|
||||
1. Click **Add people**.
|
||||
1. In the search field, start typing the name of person you want to invite, then click a name in the list of matches.
|
||||
1. Click **Add NAME to REPOSITORY**.
|
||||
{% else %}
|
||||
1. In the left sidebar, click **Collaborators**.
|
||||
1. Under "Collaborators", start typing the collaborator's username.
|
||||
1. Select the collaborator's username from the dropdown menu.
|
||||
1. Click **Add collaborator**.
|
||||
{% endif %}
|
||||
{% ifversion fpt or ghec %}
|
||||
1. The user will receive an email inviting them to the repository. Once they accept your invitation, they will have collaborator access to your repository.
|
||||
{% endif %}
|
||||
|
||||
@@ -30,13 +30,8 @@ While forks of private repositories are deleted when a collaborator is removed,
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
{% data reusables.repositories.click-collaborators-teams %}
|
||||
1. To the right of the collaborator you want to remove, click **Remove**.
|
||||
{% else %}
|
||||
1. In the left sidebar, click **Collaborators & teams**.
|
||||
1. Next to the collaborator you want to remove, click {% octicon "x" aria-label="Remove" %}.
|
||||
{% endif %}
|
||||
|
||||
## Further reading
|
||||
|
||||
|
||||
@@ -21,10 +21,6 @@ topics:
|
||||
shortTitle: Remove yourself
|
||||
---
|
||||
{% data reusables.user-settings.access_settings %}
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
1. In the "Code, planning, and automation" section of the sidebar, click **{% octicon "repo" aria-hidden="true" %} Repositories**.
|
||||
{% else %}
|
||||
1. In the left sidebar, click **Repositories**.
|
||||
{% endif %}
|
||||
1. Next to the repository you want to leave, click **Leave**.
|
||||
1. Read the warning carefully, then click **I understand, leave this repository.**
|
||||
|
||||
@@ -30,7 +30,7 @@ You can configure your CD workflow to run when a {% data variables.product.produ
|
||||
|
||||
{% data variables.product.prodname_actions %} provides features that give you more control over deployments. For example, you can use environments to require approval for a job to proceed, restrict which branches can trigger a workflow, or limit access to secrets. You can use concurrency to limit your CD pipeline to a maximum of one in-progress deployment and one pending deployment. For more information about these features, see "[AUTOTITLE](/actions/deployment/about-deployments/deploying-with-github-actions)" and "[AUTOTITLE](/actions/deployment/targeting-different-environments/using-environments-for-deployment)."
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
|
||||
## Using OpenID Connect to access cloud resources
|
||||
|
||||
|
||||
@@ -25,7 +25,7 @@ This guide explains how to use {% data variables.product.prodname_actions %} to
|
||||
|
||||
On every new push to `main` in your {% data variables.product.company_short %} repository, the {% data variables.product.prodname_actions %} workflow builds and pushes a new container image to Amazon ECR, and then deploys a new task definition to Amazon ECS.
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ topics:
|
||||
|
||||
This guide explains how to use {% data variables.product.prodname_actions %} to build and deploy a Docker container to [Azure App Service](https://azure.microsoft.com/services/app-service/).
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ topics:
|
||||
|
||||
This guide explains how to use {% data variables.product.prodname_actions %} to build and deploy a Java project to [Azure App Service](https://azure.microsoft.com/services/app-service/).
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ topics:
|
||||
|
||||
This guide explains how to use {% data variables.product.prodname_actions %} to build and deploy a .NET project to [Azure App Service](https://azure.microsoft.com/services/app-service/).
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
||||
@@ -24,7 +24,7 @@ topics:
|
||||
|
||||
This guide explains how to use {% data variables.product.prodname_actions %} to build, test, and deploy a Node.js project to [Azure App Service](https://azure.microsoft.com/services/app-service/).
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ topics:
|
||||
|
||||
This guide explains how to use {% data variables.product.prodname_actions %} to build and deploy a PHP project to [Azure App Service](https://azure.microsoft.com/services/app-service/).
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ topics:
|
||||
|
||||
This guide explains how to use {% data variables.product.prodname_actions %} to build and deploy a Python project to [Azure App Service](https://azure.microsoft.com/services/app-service/).
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ topics:
|
||||
|
||||
This guide explains how to use {% data variables.product.prodname_actions %} to build and deploy a project to [Azure Kubernetes Service](https://azure.microsoft.com/services/kubernetes-service/).
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ topics:
|
||||
|
||||
This guide explains how to use {% data variables.product.prodname_actions %} to build and deploy a web app to [Azure Static Web Apps](https://azure.microsoft.com/services/app-service/static/).
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
||||
@@ -25,7 +25,7 @@ This guide explains how to use {% data variables.product.prodname_actions %} to
|
||||
|
||||
GKE is a managed Kubernetes cluster service from Google Cloud that can host your containerized workloads in the cloud or in your own datacenter. For more information, see [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine).
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ intro: OpenID Connect allows your workflows to exchange short-lived tokens direc
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '>=3.5'
|
||||
ghes: '*'
|
||||
type: tutorial
|
||||
topics:
|
||||
- Security
|
||||
|
||||
@@ -5,7 +5,7 @@ intro: Use OpenID Connect within your workflows to authenticate with Amazon Web
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '>=3.5'
|
||||
ghes: '*'
|
||||
type: tutorial
|
||||
topics:
|
||||
- Security
|
||||
|
||||
@@ -5,7 +5,7 @@ intro: Use OpenID Connect within your workflows to authenticate with Azure.
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '>=3.5'
|
||||
ghes: '*'
|
||||
type: tutorial
|
||||
topics:
|
||||
- Security
|
||||
|
||||
@@ -5,7 +5,7 @@ intro: Use OpenID Connect within your workflows to authenticate with cloud provi
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '>=3.5'
|
||||
ghes: '*'
|
||||
type: tutorial
|
||||
topics:
|
||||
- Security
|
||||
|
||||
@@ -5,7 +5,7 @@ intro: Use OpenID Connect within your workflows to authenticate with Google Clou
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '>=3.5'
|
||||
ghes: '*'
|
||||
type: tutorial
|
||||
topics:
|
||||
- Security
|
||||
|
||||
@@ -5,7 +5,7 @@ intro: Use OpenID Connect within your workflows to authenticate with HashiCorp V
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '>=3.5'
|
||||
ghes: '*'
|
||||
type: tutorial
|
||||
topics:
|
||||
- Security
|
||||
|
||||
@@ -5,7 +5,7 @@ intro: Use OpenID Connect within your workflows to authenticate with your cloud
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '>=3.5'
|
||||
ghes: '*'
|
||||
children:
|
||||
- /about-security-hardening-with-openid-connect
|
||||
- /configuring-openid-connect-in-amazon-web-services
|
||||
|
||||
@@ -7,7 +7,7 @@ redirect_from:
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '>=3.5'
|
||||
ghes: '*'
|
||||
type: how_to
|
||||
topics:
|
||||
- Workflows
|
||||
|
||||
@@ -53,7 +53,7 @@ For more information about installing and using self-hosted runners, see "[AUTOT
|
||||
- Use free minutes on your {% data variables.product.prodname_dotcom %} plan, with per-minute rates applied after surpassing the free minutes.
|
||||
|
||||
**Self-hosted runners:**{% endif %}
|
||||
- Receive automatic updates for the self-hosted runner application only{% ifversion fpt or ghec or ghes > 3.4 or ghae %}, though you may disable automatic updates of the runner. For more information about controlling runner software updates on self-hosted runners, see "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/autoscaling-with-self-hosted-runners#controlling-runner-software-updates-on-self-hosted-runners)."{% else %}.{% endif %} You are responsible for updating the operating system and all other software.
|
||||
- Receive automatic updates for the self-hosted runner application only, though you may disable automatic updates of the runner. For more information about controlling runner software updates on self-hosted runners, see "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/autoscaling-with-self-hosted-runners#controlling-runner-software-updates-on-self-hosted-runners)." You are responsible for updating the operating system and all other software.
|
||||
- Can use cloud services or local machines that you already pay for.
|
||||
- Are customizable to your hardware, operating system, software, and security requirements.
|
||||
- Don't need to have a clean instance for every job execution.
|
||||
|
||||
@@ -66,8 +66,6 @@ Alternatively, you can create ephemeral, just-in-time runners using the REST API
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae %}
|
||||
|
||||
## Controlling runner software updates on self-hosted runners
|
||||
|
||||
By default, self-hosted runners will automatically perform a software update whenever a new version of the runner software is available. If you use ephemeral runners in containers then this can lead to repeated software updates when a new runner version is released. Turning off automatic updates allows you to update the runner version on the container image directly on your own schedule.
|
||||
@@ -90,8 +88,6 @@ For instructions on how to install the latest runner version, see the installati
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Using webhooks for autoscaling
|
||||
|
||||
You can create your own autoscaling environment by using payloads received from the [`workflow_job`](/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_job) webhook. This webhook is available at the repository, organization, and enterprise levels, and the payload for this event contains an `action` key that corresponds to the stages of a workflow job's life-cycle; for example when jobs are `queued`, `in_progress`, and `completed`. You must then create your own scaling automation in response to these webhook payloads.
|
||||
|
||||
@@ -826,8 +826,6 @@ The `inputs` context contains input properties passed to an action{% ifversion a
|
||||
|
||||
The properties in the `inputs` context are defined in the workflow file. They are only available in a [reusable workflow](/actions/using-workflows/reusing-workflows){% ifversion actions-unified-inputs %} or in a workflow triggered by the [`workflow_dispatch` event](/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch){% endif %}
|
||||
|
||||
{% data reusables.actions.reusable-workflows-enterprise-beta %}
|
||||
|
||||
| Property name | Type | Description |
|
||||
|---------------|------|-------------|
|
||||
| `inputs` | `object` | This context is only available in a [reusable workflow](/actions/using-workflows/reusing-workflows){% ifversion actions-unified-inputs %} or in a workflow triggered by the [`workflow_dispatch` event](/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch){% endif %}. You can access this context from any job or step in a workflow. This object contains the properties listed below. |
|
||||
|
||||
@@ -88,8 +88,6 @@ In addition to the usage limits, you must ensure that you use {% data variables.
|
||||
|
||||
## Billing for reusable workflows
|
||||
|
||||
{% data reusables.actions.reusable-workflows-enterprise-beta %}
|
||||
|
||||
If you reuse a workflow, billing is always associated with the caller workflow. Assignment of {% data variables.product.prodname_dotcom %}-hosted runners is always evaluated using only the caller's context. The caller cannot use {% data variables.product.prodname_dotcom %}-hosted runners from the called repository.
|
||||
|
||||
For more information see, "[AUTOTITLE](/actions/using-workflows/reusing-workflows)."
|
||||
|
||||
@@ -26,14 +26,12 @@ Re-running a workflow{% ifversion re-run-jobs %} or jobs in a workflow{% endif %
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
{% data reusables.repositories.navigate-to-workflow %}
|
||||
{% data reusables.repositories.view-run %}
|
||||
{% ifversion fpt or ghes > 3.4 or ghae or ghec -%}
|
||||
1. In the upper-right corner of the workflow, re-run jobs.
|
||||
|
||||
- If any jobs failed, select the **{% octicon "sync" aria-hidden="true" %} Re-run jobs** dropdown menu and click **Re-run all jobs**.
|
||||
|
||||
- If no jobs failed, click **Re-run all jobs**.
|
||||
{%- endif %}
|
||||
{% ifversion ghes < 3.5 or ghae -%}
|
||||
{% ifversion ghae -%}
|
||||
1. In the upper-right corner of the workflow, select the **Re-run jobs** dropdown menu and click **Re-run all jobs**.
|
||||
{%- endif %}
|
||||
{% data reusables.actions.enable-debug-logging %}
|
||||
@@ -147,8 +145,6 @@ gh run rerun --job JOB_ID --debug
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% ifversion fpt or ghes > 3.4 or ghae or ghec %}
|
||||
|
||||
## Reviewing previous workflow runs
|
||||
|
||||
You can view the results from your previous attempts at running a workflow. You can also view previous workflow runs using the API. For more information, see "[AUTOTITLE](/rest/actions#get-a-workflow-run)."
|
||||
@@ -164,4 +160,3 @@ You can view the results from your previous attempts at running a workflow. You
|
||||
{%- else %}
|
||||
1. In the left pane, click a previous run attempt.
|
||||
{%- endif %}
|
||||
{% endif %}
|
||||
|
||||
@@ -44,7 +44,7 @@ You might also find it helpful to have a basic understanding of the following:
|
||||
|
||||
This guide assumes that you have a complete definition for a Docker image stored in a {% data variables.product.prodname_dotcom %} repository. For example, your repository must contain a _Dockerfile_, and any other files needed to perform a Docker build to create an image.
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
|
||||
{% data reusables.package_registry.about-annotation-keys %} For more information, see "[AUTOTITLE](/packages/working-with-a-github-packages-registry/working-with-the-container-registry#labelling-container-images)."
|
||||
|
||||
@@ -117,7 +117,7 @@ The above workflow checks out the {% data variables.product.prodname_dotcom %} r
|
||||
|
||||
## Publishing images to {% data variables.product.prodname_registry %}
|
||||
|
||||
{% ifversion ghes > 3.4 %}
|
||||
{% ifversion ghes %}
|
||||
{% data reusables.package_registry.container-registry-ghes-beta %}
|
||||
{% endif %}
|
||||
|
||||
@@ -126,7 +126,7 @@ The above workflow checks out the {% data variables.product.prodname_dotcom %} r
|
||||
In the example workflow below, we use the Docker `login-action`{% ifversion fpt or ghec %}, `metadata-action`,{% endif %} and `build-push-action` actions to build the Docker image, and if the build succeeds, push the built image to {% data variables.product.prodname_registry %}.
|
||||
|
||||
The `login-action` options required for {% data variables.product.prodname_registry %} are:
|
||||
- `registry`: Must be set to {% ifversion fpt or ghec %}`ghcr.io`{% elsif ghes > 3.4 %}`{% data reusables.package_registry.container-registry-hostname %}`{% else %}`docker.pkg.github.com`{% endif %}.
|
||||
- `registry`: Must be set to {% ifversion fpt or ghec %}`ghcr.io`{% elsif ghes %}`{% data reusables.package_registry.container-registry-hostname %}`{% else %}`docker.pkg.github.com`{% endif %}.
|
||||
- `username`: You can use the {% raw %}`${{ github.actor }}`{% endraw %} context to automatically use the username of the user that triggered the workflow run. For more information, see "[AUTOTITLE](/actions/learn-github-actions/contexts#github-context)."
|
||||
- `password`: You can use the automatically-generated `GITHUB_TOKEN` secret for the password. For more information, see "[AUTOTITLE](/actions/security-guides/automatic-token-authentication)."
|
||||
|
||||
@@ -140,13 +140,13 @@ The `build-push-action` options required for {% data variables.product.prodname_
|
||||
- `context`: Defines the build's context as the set of files located in the specified path.{% endif %}
|
||||
- `push`: If set to `true`, the image will be pushed to the registry if it is built successfully.{% ifversion fpt or ghec %}
|
||||
- `tags` and `labels`: These are populated by output from `metadata-action`.{% else %}
|
||||
- `tags`: Must be set in the format {% ifversion ghes > 3.4 %}`{% data reusables.package_registry.container-registry-hostname %}/OWNER/REPOSITORY/IMAGE_NAME:VERSION`.
|
||||
- `tags`: Must be set in the format {% ifversion ghes %}`{% data reusables.package_registry.container-registry-hostname %}/OWNER/REPOSITORY/IMAGE_NAME:VERSION`.
|
||||
|
||||
For example, for an image named `octo-image` stored on {% data variables.product.prodname_ghe_server %} at `https://HOSTNAME/octo-org/octo-repo`, the `tags` option should be set to `{% data reusables.package_registry.container-registry-hostname %}/octo-org/octo-repo/octo-image:latest`{% else %}`docker.pkg.github.com/OWNER/REPOSITORY/IMAGE_NAME:VERSION`.
|
||||
|
||||
For example, for an image named `octo-image` stored on {% data variables.product.prodname_dotcom %} at `http://github.com/octo-org/octo-repo`, the `tags` option should be set to `docker.pkg.github.com/octo-org/octo-repo/octo-image:latest`{% endif %}. You can set a single tag as shown below, or specify multiple tags in a list.{% endif %}
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
{% data reusables.package_registry.publish-docker-image %}
|
||||
|
||||
The above workflow is triggered by a push to the "release" branch. It checks out the GitHub repository, and uses the `login-action` to log in to the {% data variables.product.prodname_container_registry %}. It then extracts labels and tags for the Docker image. Finally, it uses the `build-push-action` action to build the image and publish it on the {% data variables.product.prodname_container_registry %}.
|
||||
@@ -196,7 +196,7 @@ The above workflow checks out the {% data variables.product.product_name %} repo
|
||||
|
||||
## Publishing images to Docker Hub and {% data variables.product.prodname_registry %}
|
||||
|
||||
{% ifversion ghes > 3.4 %}
|
||||
{% ifversion ghes %}
|
||||
{% data reusables.package_registry.container-registry-ghes-beta %}
|
||||
{% endif %}
|
||||
|
||||
@@ -232,10 +232,10 @@ jobs:
|
||||
username: {% raw %}${{ secrets.DOCKER_USERNAME }}{% endraw %}
|
||||
password: {% raw %}${{ secrets.DOCKER_PASSWORD }}{% endraw %}
|
||||
|
||||
- name: Log in to the {% ifversion fpt or ghec or ghes > 3.4 %}Container{% else %}Docker{% endif %} registry
|
||||
- name: Log in to the {% ifversion fpt or ghec or ghes %}Container{% else %}Docker{% endif %} registry
|
||||
uses: docker/login-action@65b78e6e13532edd9afa3aa52ac7964289d1a9c1
|
||||
with:
|
||||
registry: {% ifversion fpt or ghec %}ghcr.io{% elsif ghae %}docker.YOUR-HOSTNAME.com{% elsif ghes > 3.4 %}{% data reusables.package_registry.container-registry-hostname %}{% else %}docker.pkg.github.com{% endif %}
|
||||
registry: {% ifversion fpt or ghec %}ghcr.io{% elsif ghae %}docker.YOUR-HOSTNAME.com{% elsif ghes %}{% data reusables.package_registry.container-registry-hostname %}{% else %}docker.pkg.github.com{% endif %}
|
||||
username: {% raw %}${{ github.actor }}{% endraw %}
|
||||
password: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
|
||||
|
||||
@@ -245,7 +245,7 @@ jobs:
|
||||
with:
|
||||
images: |
|
||||
my-docker-hub-namespace/my-docker-hub-repository
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}{% data reusables.package_registry.container-registry-hostname %}/{% raw %}${{ github.repository }}{% endraw %}{% elsif ghae %}{% raw %}docker.YOUR-HOSTNAME.com/${{ github.repository }}/my-image{% endraw %}{% else %}{% raw %}docker.pkg.github.com/${{ github.repository }}/my-image{% endraw %}{% endif %}
|
||||
{% ifversion fpt or ghec or ghes %}{% data reusables.package_registry.container-registry-hostname %}/{% raw %}${{ github.repository }}{% endraw %}{% elsif ghae %}{% raw %}docker.YOUR-HOSTNAME.com/${{ github.repository }}/my-image{% endraw %}{% else %}{% raw %}docker.pkg.github.com/${{ github.repository }}/my-image{% endraw %}{% endif %}
|
||||
|
||||
- name: Build and push Docker images
|
||||
uses: docker/build-push-action@3b5e8027fcad23fda98b2e3ac259d8d67585f671
|
||||
@@ -257,4 +257,4 @@ jobs:
|
||||
```
|
||||
|
||||
The above workflow checks out the {% data variables.product.product_name %} repository, uses the `login-action` twice to log in to both registries and generates tags and labels with the `metadata-action` action.
|
||||
Then the `build-push-action` action builds and pushes the Docker image to Docker Hub and the {% ifversion fpt or ghec or ghes > 3.4 %}{% data variables.product.prodname_container_registry %}{% else %}Docker registry{% endif %}.
|
||||
Then the `build-push-action` action builds and pushes the Docker image to Docker Hub and the {% ifversion fpt or ghec or ghes %}{% data variables.product.prodname_container_registry %}{% else %}Docker registry{% endif %}.
|
||||
|
||||
@@ -25,7 +25,7 @@ Secrets are variables that you create in an organization, repository, or reposit
|
||||
|
||||
For secrets stored at the environment level, you can enable required reviewers to control access to the secrets. A workflow job cannot access environment secrets until approval is granted by required approvers.
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
||||
@@ -173,7 +173,7 @@ For more information, see "[AUTOTITLE](/code-security/code-scanning/automaticall
|
||||
|
||||
To help mitigate the risk of an exposed token, consider restricting the assigned permissions. For more information, see "[AUTOTITLE](/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token)."
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
|
||||
## Using OpenID Connect to access cloud resources
|
||||
|
||||
@@ -365,7 +365,7 @@ A self-hosted runner can be added to various levels in your {% data variables.pr
|
||||
- If each team will manage their own self-hosted runners, then the recommendation is to add the runners at the highest level of team ownership. For example, if each team owns their own organization, then it will be simplest if the runners are added at the organization level too.
|
||||
- You could also add runners at the repository level, but this will add management overhead and also increases the numbers of runners you need, since you cannot share runners between repositories.
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
|
||||
### Authenticating to your cloud provider
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ By default, {% data variables.product.prodname_dotcom %}-hosted runners have acc
|
||||
|
||||
{% data variables.product.prodname_dotcom %}-hosted runners are shared across all {% data variables.product.prodname_dotcom %} customers, so you will need a way of connecting your private network to just your runners while they are running your workflows. There are a few different approaches you could take to configure this access, each with different advantages and disadvantages.
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
|
||||
### Using an API Gateway with OIDC
|
||||
|
||||
|
||||
@@ -14,7 +14,6 @@ topics:
|
||||
- Workflows
|
||||
---
|
||||
|
||||
{% data reusables.actions.reusable-workflows-enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
## Overview
|
||||
@@ -201,7 +200,7 @@ You call a reusable workflow by using the `uses` keyword. Unlike when you are us
|
||||
|
||||
[`jobs.<job_id>.uses`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iduses)
|
||||
|
||||
You reference reusable workflow files using {% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}one of the following syntaxes:{% else %}the syntax:{% endif %}
|
||||
You reference reusable workflow files using one of the following syntaxes:
|
||||
|
||||
{% data reusables.actions.reusable-workflow-calling-syntax %}
|
||||
|
||||
|
||||
@@ -126,8 +126,6 @@ You can use activity types and filters to further control when your workflow wil
|
||||
|
||||
## Defining inputs, outputs, and secrets for reusable workflows
|
||||
|
||||
{% data reusables.actions.reusable-workflows-enterprise-beta %}
|
||||
|
||||
You can define inputs and secrets that a reusable workflow should receive from a calling workflow. You can also specify outputs that a reusable workflow will make available to a calling workflow. For more information, see "[AUTOTITLE](/actions/using-workflows/reusing-workflows)."
|
||||
|
||||
## Using event information
|
||||
|
||||
@@ -14,7 +14,7 @@ versions:
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
---
|
||||
|
||||
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
## About YAML syntax for workflows
|
||||
@@ -72,8 +72,6 @@ run-name: Deploy to ${{ inputs.deploy_target }} by @${{ github.actor }}
|
||||
|
||||
## `on.workflow_call`
|
||||
|
||||
{% data reusables.actions.reusable-workflows-enterprise-beta %}
|
||||
|
||||
Use `on.workflow_call` to define the inputs and outputs for a reusable workflow. You can also map the secrets that are available to the called workflow. For more information on reusable workflows, see "[AUTOTITLE](/actions/using-workflows/reusing-workflows)."
|
||||
|
||||
## `on.workflow_call.inputs`
|
||||
@@ -1005,9 +1003,7 @@ Additional Docker container resource options. For a list of options, see "[`dock
|
||||
|
||||
## `jobs.<job_id>.uses`
|
||||
|
||||
{% data reusables.actions.reusable-workflows-enterprise-beta %}
|
||||
|
||||
The location and version of a reusable workflow file to run as a job. {% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}Use one of the following syntaxes:{% endif %}
|
||||
The location and version of a reusable workflow file to run as a job. Use one of the following syntaxes:
|
||||
|
||||
{% data reusables.actions.reusable-workflow-calling-syntax %}
|
||||
|
||||
|
||||
@@ -23,7 +23,7 @@ shortTitle: Automatic user license sync
|
||||
|
||||
{% data reusables.enterprise-licensing.about-license-sync %} For more information, see "[AUTOTITLE](/admin/configuration/configuring-github-connect/about-github-connect#data-transmission-for-github-connect)."
|
||||
|
||||
If you enable automatic user license sync for your enterprise, {% data variables.product.prodname_github_connect %} will automatically synchronize license usage between {% data variables.product.prodname_ghe_server %} and {% data variables.product.prodname_ghe_cloud %} weekly.{% ifversion ghes > 3.4 %} You can also synchronize your license data at any time outside of the automatic weekly sync, by manually triggering a license sync job. For more information, see "[AUTOTITLE](/billing/managing-your-license-for-github-enterprise/syncing-license-usage-between-github-enterprise-server-and-github-enterprise-cloud#triggering-a-license-sync-job)."{% endif %}
|
||||
If you enable automatic user license sync for your enterprise, {% data variables.product.prodname_github_connect %} will automatically synchronize license usage between {% data variables.product.prodname_ghe_server %} and {% data variables.product.prodname_ghe_cloud %} weekly.{% ifversion ghes %} You can also synchronize your license data at any time outside of the automatic weekly sync, by manually triggering a license sync job. For more information, see "[AUTOTITLE](/billing/managing-your-license-for-github-enterprise/syncing-license-usage-between-github-enterprise-server-and-github-enterprise-cloud#triggering-a-license-sync-job)."{% endif %}
|
||||
|
||||
If you use multiple {% data variables.product.prodname_ghe_server %} instances, you can enable automatic license sync between each of your instances and the same enterprise account on {% data variables.product.prodname_ghe_cloud %}.
|
||||
|
||||
|
||||
@@ -120,7 +120,7 @@ After you enable {% data variables.product.prodname_dependabot_alerts %} for you
|
||||
{% data variables.product.prodname_dependabot_updates %} are not supported on {% data variables.product.product_name %} if your enterprise uses clustering.
|
||||
{% endif %}
|
||||
|
||||
{% ifversion ghes > 3.4 %}
|
||||
{% ifversion ghes %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ redirect_from:
|
||||
- /enterprise/admin/installation/configuring-an-outbound-web-proxy-server
|
||||
- /enterprise/admin/configuration/configuring-an-outbound-web-proxy-server
|
||||
- /admin/configuration/configuring-an-outbound-web-proxy-server
|
||||
permissions: Site administrators can configure an outbound web proxy server for a {% data variables.product.product_name %} instance.
|
||||
permissions: 'Site administrators can configure an outbound web proxy server for a {% data variables.product.product_name %} instance.'
|
||||
versions:
|
||||
ghes: '*'
|
||||
type: how_to
|
||||
@@ -49,7 +49,7 @@ Your instance validates the hostnames for proxy exclusion using the list of IANA
|
||||
{%- ifversion ghes < 3.9 %}
|
||||
{% note %}
|
||||
|
||||
**Note**: In {% data variables.product.product_name %} 3.{% ifversion ghes = 3.4 %}4.18{% elsif ghes = 3.5 %}5.15{% elsif ghes = 3.6 %}6.11{% elsif ghes = 3.7%}7.8{% elsif ghes = 3.8 %}8.1{% endif %} and later, your instance validates the hostnames using the list of IANA's registered top-level domains (TLDs). For more information, see the [list of TLDs](https://data.iana.org/TLD/tlds-alpha-by-domain.txt) on the IANA website. If you want to exclude an unregistered TLD, see "[Excluding additional unregistered TLDs from the proxy](#excluding-additional-unregistered-tlds-from-the-proxy)."
|
||||
**Note**: In {% data variables.product.product_name %} 3.{% ifversion ghes = 3.5 %}5.15{% elsif ghes = 3.6 %}6.11{% elsif ghes = 3.7%}7.8{% elsif ghes = 3.8 %}8.1{% endif %} and later, your instance validates the hostnames using the list of IANA's registered top-level domains (TLDs). For more information, see the [list of TLDs](https://data.iana.org/TLD/tlds-alpha-by-domain.txt) on the IANA website. If you want to exclude an unregistered TLD, see "[Excluding additional unregistered TLDs from the proxy](#excluding-additional-unregistered-tlds-from-the-proxy)."
|
||||
|
||||
{% endnote %}
|
||||
{%- endif %}
|
||||
@@ -57,7 +57,7 @@ Your instance validates the hostnames for proxy exclusion using the list of IANA
|
||||
|
||||
## Excluding additional unregistered TLDs from the proxy
|
||||
|
||||
{% ifversion ghes < 3.9 %}In {% data variables.product.product_name %} 3.{% ifversion ghes = 3.4 %}4.18{% elsif ghes = 3.5 %}5.15{% elsif ghes = 3.6 %}6.11{% elsif ghes = 3.7%}7.8{% elsif ghes = 3.8 %}8.1{% endif %} and later, you{% elsif ghes > 3.8 %}You{% endif %} can configure your instance's proxy settings to exclude unregistered TLDs that aren't specified in the [list of TLDs](https://data.iana.org/TLD/tlds-alpha-by-domain.txt) on the IANA website.
|
||||
{% ifversion ghes < 3.9 %}In {% data variables.product.product_name %} 3.{% ifversion ghes = 3.5 %}5.15{% elsif ghes = 3.6 %}6.11{% elsif ghes = 3.7%}7.8{% elsif ghes = 3.8 %}8.1{% endif %} and later, you{% elsif ghes > 3.8 %}You{% endif %} can configure your instance's proxy settings to exclude unregistered TLDs that aren't specified in the [list of TLDs](https://data.iana.org/TLD/tlds-alpha-by-domain.txt) on the IANA website.
|
||||
|
||||
{% data reusables.enterprise_installation.ssh-into-instance %}
|
||||
1. Enter the following command, replacing COMMA-SEPARATED-TLD-LIST with a comma-separated list of TLDs.
|
||||
|
||||
@@ -50,7 +50,7 @@ When subdomain isolation is enabled, {% data variables.product.prodname_ghe_serv
|
||||
{%- ifversion viewscreen-and-notebooks %}
|
||||
| `http(s)://HOSTNAME/viewscreen/` | `http(s)://viewscreen.HOSTNAME/` |
|
||||
{%- endif %}
|
||||
{%- ifversion ghes > 3.4 %}
|
||||
{%- ifversion ghes %}
|
||||
| Not supported | `https://containers.HOSTNAME/` |
|
||||
{%- endif %}
|
||||
|
||||
|
||||
@@ -299,10 +299,10 @@ ghe-saml-mapping-csv -d
|
||||
|
||||
{% ifversion ghes < 3.9 %}
|
||||
|
||||
After output completes, the utility displays the path to the file. The default path for output depends on the patch release of {% data variables.product.product_name %} {% ifversion ghes = 3.4 %}3.4{% elsif ghes = 3.5 %}3.5{% elsif ghes = 3.6 %}3.6{% elsif ghes = 3.7%}3.7{% endif %} your instance is running.
|
||||
After output completes, the utility displays the path to the file. The default path for output depends on the patch release of {% data variables.product.product_name %} {% ifversion ghes = 3.5 %}3.5{% elsif ghes = 3.6 %}3.6{% elsif ghes = 3.7%}3.7{% endif %} your instance is running.
|
||||
|
||||
- In version 3.{% ifversion ghes = 3.4 %}4.17{% elsif ghes = 3.5 %}5.14{% elsif ghes = 3.6 %}6.10{% elsif ghes = 3.7%}7.7{% elsif ghes = 3.8 %}8.0{% endif %}{% ifversion ghes < 3.8 %} and earlier{% endif %}, the utility writes the file to `/tmp`.
|
||||
- In version 3.{% ifversion ghes = 3.4 %}4.18{% elsif ghes = 3.5 %}5.15{% elsif ghes = 3.6 %}6.11{% elsif ghes = 3.7%}7.8{% elsif ghes = 3.8 %}8.1{% endif %} and later,
|
||||
- In version 3.{% ifversion ghes = 3.5 %}5.14{% elsif ghes = 3.6 %}6.10{% elsif ghes = 3.7%}7.7{% elsif ghes = 3.8 %}8.0{% endif %}{% ifversion ghes < 3.8 %} and earlier{% endif %}, the utility writes the file to `/tmp`.
|
||||
- In version 3.{% ifversion ghes = 3.5 %}5.15{% elsif ghes = 3.6 %}6.11{% elsif ghes = 3.7%}7.8{% elsif ghes = 3.8 %}8.1{% endif %} and later,
|
||||
|
||||
{%- elsif ghes > 3.8 %}By default,{% endif %} the utility writes the file to `/data/user/tmp`.
|
||||
|
||||
|
||||
@@ -59,7 +59,7 @@ If subdomain isolation is disabled for your enterprise, you should also disable
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% ifversion ghes > 3.4 %}
|
||||
{% ifversion ghes %}
|
||||
|
||||
## Configuring {% data variables.product.prodname_pages %} response headers for your enterprise
|
||||
|
||||
|
||||
@@ -74,7 +74,7 @@ If a member of {% data variables.product.company_short %}'s staff has recommende
|
||||
1. Under "User ID Limit", type a limit for each user ID.
|
||||
{% data reusables.enterprise_management_console.save-settings %}
|
||||
|
||||
{% ifversion ghes > 3.4 %}
|
||||
{% ifversion ghes %}
|
||||
|
||||
## Configuring rate limits for {% data variables.product.prodname_actions %}
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Configuring web commit signing
|
||||
shortTitle: Configure web commit signing
|
||||
intro: 'You can enable auto-signing of commits made in the web interface of {% data variables.product.product_name %}.'
|
||||
versions:
|
||||
ghes: '>=3.5'
|
||||
ghes: '*'
|
||||
type: how_to
|
||||
topics:
|
||||
- Access management
|
||||
|
||||
@@ -56,15 +56,6 @@ You can perform initial validation of your maintenance operation by configuring
|
||||
|
||||
## Validating changes in maintenance mode using the IP exception list
|
||||
|
||||
{% ifversion ghes = 3.4 %}
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note**: To validate changes in maintenance mode using the IP exception list, your {% data variables.product.product_name %} instance must be running version 3.4.4 or later.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
The IP exception list provides controlled and restricted access to {% data variables.location.product_location %}, which is ideal for initial validation of server health following a maintenance operation. Once enabled, {% data variables.location.product_location %} will be taken out of maintenance mode and available only to the configured IP addresses. The maintenance mode checkbox will be updated to reflect the change in state.
|
||||
|
||||
|
||||
@@ -272,12 +272,12 @@ To upgrade an instance that comprises multiple nodes using an upgrade package, y
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{%- ifversion ghes = 3.4 or ghes = 3.5 or ghes = 3.6 %}
|
||||
{%- ifversion ghes = 3.5 or ghes = 3.6 %}
|
||||
|
||||
- If you have upgraded each node to {% data variables.product.product_name %} 3.6.0 or later and started replication, but `git replication is behind the primary` continues to appear after 45 minutes, contact {% data variables.contact.enterprise_support %}. For more information, see "[AUTOTITLE](/support/contacting-github-support)."
|
||||
{%- endif %}
|
||||
|
||||
- {% ifversion ghes = 3.4 or ghes = 3.5 or ghes = 3.6 %}Otherwise, if{% else %}If{% endif %} `ghe-repl-status` did not return `OK`, contact {% data variables.contact.enterprise_support %}. For more information, see "[AUTOTITLE](/support/contacting-github-support)."
|
||||
- {% ifversion ghes = 3.5 or ghes = 3.6 %}Otherwise, if{% else %}If{% endif %} `ghe-repl-status` did not return `OK`, contact {% data variables.contact.enterprise_support %}. For more information, see "[AUTOTITLE](/support/contacting-github-support)."
|
||||
{% data reusables.enterprise_installation.multiple-node-repeat-upgrade-process %}
|
||||
1. After you have upgraded the last replica node and the resync is complete, disable maintenance mode so users can use {% data variables.location.product_location %}.
|
||||
|
||||
|
||||
@@ -43,9 +43,7 @@ Any VM that you use for {% data variables.product.prodname_dependabot %} runners
|
||||
|
||||
- Linux operating system
|
||||
- x64 architecture
|
||||
{%- ifversion ghes < 3.5 %}
|
||||
- Git installed
|
||||
{%- endif %}
|
||||
|
||||
- Docker installed with access for the runner users:
|
||||
- We recommend installing Docker in rootless mode and configuring the runners to access Docker without `root` privileges.
|
||||
- Alternatively, install Docker and give the runner users raised privileges to run Docker.
|
||||
@@ -70,9 +68,7 @@ If you specify more than 14 concurrent runners on a VM, you must also update the
|
||||
|
||||
1. Provision self-hosted runners, at the repository, organization, or enterprise account level. For more information, see "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners)" and "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners)."
|
||||
|
||||
1. Set up the self-hosted runners with the requirements described above. For example, on a VM running Ubuntu 20.04 you would:{% ifversion ghes < 3.5 %}
|
||||
|
||||
- Verify that Git is installed: `command -v git`{% endif %}
|
||||
1. Set up the self-hosted runners with the requirements described above. For example, on a VM running Ubuntu 20.04 you would:
|
||||
- Install Docker and ensure that the runner users have access to Docker. For more information, see the Docker documentation.
|
||||
- [Install Docker Engine on Ubuntu](https://docs.docker.com/engine/install/ubuntu/)
|
||||
- Recommended approach: [Run the Docker daemon as a non-root user (Rootless mode)](https://docs.docker.com/engine/security/rootless/)
|
||||
|
||||
@@ -32,7 +32,7 @@ You can create your own unique automations, or you can use and adapt workflows f
|
||||
|
||||
{% ifversion ghec %}You can enjoy the convenience of {% data variables.product.company_short %}-hosted runners, which are maintained and upgraded by {% data variables.product.company_short %}, or you{% else %}You{% endif %} can control your own private CI/CD infrastructure by using self-hosted runners. Self-hosted runners allow you to determine the exact environment and resources that complete your builds, testing, and deployments, without exposing your software development cycle to the internet. For more information, see {% ifversion ghec %}"[AUTOTITLE](/actions/using-github-hosted-runners/about-github-hosted-runners)" and{% endif %} "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners)."
|
||||
|
||||
{% data variables.product.prodname_actions %} provides greater control over deployments. For example, you can use environments to require approval for a job to proceed, restrict which branches can trigger a workflow, or limit access to secrets.{% ifversion ghec or ghes > 3.4 %} If your workflows need to access resources from a cloud provider that supports OpenID Connect (OIDC), you can configure your workflows to authenticate directly to the cloud provider. OIDC provides security benefits such as eliminating the need to store credentials as long-lived secrets. For more information, see "[AUTOTITLE](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect)."{% endif %}
|
||||
{% data variables.product.prodname_actions %} provides greater control over deployments. For example, you can use environments to require approval for a job to proceed, restrict which branches can trigger a workflow, or limit access to secrets.{% ifversion ghec or ghes %} If your workflows need to access resources from a cloud provider that supports OpenID Connect (OIDC), you can configure your workflows to authenticate directly to the cloud provider. OIDC provides security benefits such as eliminating the need to store credentials as long-lived secrets. For more information, see "[AUTOTITLE](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect)."{% endif %}
|
||||
|
||||
{% data variables.product.prodname_actions %} also includes tools to govern your enterprise's software development cycle and meet compliance obligations. For more information, see "[AUTOTITLE](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise)."
|
||||
|
||||
|
||||
@@ -14,7 +14,8 @@ type: how_to
|
||||
topics:
|
||||
- Actions
|
||||
- Enterprise
|
||||
---
|
||||
---
|
||||
|
||||
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
@@ -46,14 +47,6 @@ The peak quantity of connected runners without performance loss depends on such
|
||||
|
||||
{% endif %}
|
||||
|
||||
{%- ifversion ghes = 3.4 %}
|
||||
|
||||
{% data reusables.actions.hardware-requirements-3.4 %}
|
||||
|
||||
Maximum concurrency was measured using multiple repositories, job duration of approximately 10 minutes, and 10 MB artifact uploads. You may experience different performance depending on the overall levels of activity on your instance.
|
||||
|
||||
{%- endif %}
|
||||
|
||||
{%- ifversion ghes = 3.5 %}
|
||||
|
||||
{% data reusables.actions.hardware-requirements-3.5 %}
|
||||
@@ -102,7 +95,7 @@ For more information about minimum hardware requirements for {% data variables.l
|
||||
|
||||
{% data reusables.enterprise_installation.about-adjusting-resources %}
|
||||
|
||||
{% ifversion ghes > 3.4 %}
|
||||
{% ifversion ghes %}
|
||||
|
||||
Optionally, you can limit resource consumption on {% data variables.location.product_location %} by configuring a rate limit for {% data variables.product.prodname_actions %}. For more information, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/configuring-rate-limits#configuring-rate-limits-for-github-actions)."
|
||||
|
||||
|
||||
@@ -28,7 +28,7 @@ Then,{% else %}First,{% endif %} decide whether you'll allow third-party actions
|
||||
|
||||
For more information, see "[AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#managing-github-actions-permissions-for-your-repository)", "[AUTOTITLE](/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#managing-github-actions-permissions-for-your-organization)", and "[AUTOTITLE](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#enforcing-a-policy-to-restrict-the-use-of-github-actions-in-your-enterprise)."
|
||||
|
||||
{% ifversion ghec or ghes > 3.4 %}
|
||||
{% ifversion ghec or ghes %}
|
||||
Consider combining OpenID Connect (OIDC) with reusable workflows to enforce consistent deployments across your repository, organization, or enterprise. You can do this by defining trust conditions on cloud roles based on reusable workflows. For more information, see "[AUTOTITLE](/actions/deployment/security-hardening-your-deployments/using-openid-connect-with-reusable-workflows)."
|
||||
{% endif %}
|
||||
|
||||
@@ -62,7 +62,6 @@ Think about how your enterprise can use features of {% data variables.product.pr
|
||||
|
||||
{% data reusables.actions.internal-actions-summary %}
|
||||
|
||||
{% data reusables.actions.reusable-workflows-enterprise-beta %}
|
||||
With reusable workflows, your team can call one workflow from another workflow, avoiding exact duplication. Reusable workflows promote best practice by helping your team use workflows that are well designed and have already been tested. For more information, see "[AUTOTITLE](/actions/using-workflows/reusing-workflows)."
|
||||
|
||||
To provide a starting place for developers building new workflows, you can use starter workflows. This not only saves time for your developers, but promotes consistency and best practice across your enterprise. For more information, see "[AUTOTITLE](/actions/using-workflows/creating-starter-workflows-for-your-organization)."
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Configuring package ecosystem support for your enterprise
|
||||
intro: 'You can configure {% data variables.product.prodname_registry %} for your enterprise by globally enabling or disabling individual package ecosystems on your enterprise, including {% ifversion ghes > 3.4 %}{% data variables.product.prodname_container_registry %}, {% endif %}Docker, and npm. Learn about other configuration requirements to support specific package ecosystems.'
|
||||
intro: 'You can configure {% data variables.product.prodname_registry %} for your enterprise by globally enabling or disabling individual package ecosystems on your enterprise, including {% ifversion ghes %}{% data variables.product.prodname_container_registry %}, {% endif %}Docker, and npm. Learn about other configuration requirements to support specific package ecosystems.'
|
||||
permissions: 'Site administrators can enable {% data variables.product.prodname_registry %} and configure enterprise settings.'
|
||||
redirect_from:
|
||||
- /enterprise/admin/packages/configuring-packages-support-for-your-enterprise
|
||||
@@ -32,7 +32,7 @@ To prevent new packages from being uploaded, you can set an ecosystem you previo
|
||||
{% data reusables.enterprise_site_admin_settings.management-console %}
|
||||
{% data reusables.enterprise_site_admin_settings.packages-tab %}
|
||||
1. Under "Ecosystem Toggles", for each package type, select **Enabled**, **Read-Only**, or **Disabled**.
|
||||
{%- ifversion ghes > 3.4 %}{% note -%}
|
||||
{%- ifversion ghes %}{% note -%}
|
||||
**Note**: Subdomain isolation must be enabled to toggle the {% data variables.product.prodname_container_registry %} options.
|
||||
{%- endnote %}{%- endif %}
|
||||

|
||||
|
||||
@@ -287,7 +287,7 @@ If you have [enabled private mode](/admin/configuration/configuring-your-enterpr
|
||||
|
||||
Enabling anonymous Git read access allows users to bypass authentication for custom tools on your enterprise. When you or a repository administrator enable this access setting for a repository, unauthenticated Git operations (and anyone with network access to {% data variables.product.product_name %}) will have read access to the repository without authentication.
|
||||
|
||||
Anonymous Git read access is disabled by default.{% ifversion ghes = 3.4 or ghes = 3.5 or ghes = 3.6 or ghes = 3.7 %} When you upgrade to {% data variables.product.product_name %} 3.6 or later, anonymous Git read access is automatically disabled at the application level, and `git://` connections on port 9418 will return the following error.
|
||||
Anonymous Git read access is disabled by default.{% ifversion ghes = 3.5 or ghes = 3.6 or ghes = 3.7 %} When you upgrade to {% data variables.product.product_name %} 3.6 or later, anonymous Git read access is automatically disabled at the application level, and `git://` connections on port 9418 will return the following error.
|
||||
|
||||
```
|
||||
The unauthenticated git protocol on port 9418 is no longer supported.
|
||||
|
||||
@@ -17,11 +17,7 @@ shortTitle: Deploy keys
|
||||
---
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
1. In the "Security" section of the sidebar, click **{% octicon "key" aria-hidden="true" %} Deploy keys**.
|
||||
{% else %}
|
||||
1. In the left sidebar, click **Deploy keys**.
|
||||
{% endif %}
|
||||
1. On the "Deploy keys" page, take note of the deploy keys associated with your account. For those that you don't recognize, or that are out of date, click **Delete**. If there are valid deploy keys you'd like to keep, click **Approve**.
|
||||
|
||||
For more information, see "[AUTOTITLE](/authentication/connecting-to-github-with-ssh/managing-deploy-keys)."
|
||||
|
||||
@@ -21,11 +21,7 @@ shortTitle: Review security log
|
||||
The security log lists all actions performed within the last 90 days.
|
||||
|
||||
{% data reusables.user-settings.access_settings %}
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
1. In the "Archives" section of the sidebar, click **{% octicon "log" aria-hidden="true" %} Security log**.
|
||||
{% else %}
|
||||
1. In the user settings sidebar, click **Security log**.
|
||||
{% endif %}
|
||||
|
||||
## Searching your security log
|
||||
|
||||
|
||||
@@ -66,7 +66,7 @@ Repository administrators can enforce required commit signing on a branch to blo
|
||||
|
||||
{% data reusables.identity-and-permissions.verification-status-check %}
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
{% ifversion ghes %}If a site administrator has enabled web commit signing, {% data variables.product.product_name %} will automatically use GPG to sign commits you make using the web interface. Commits signed by {% data variables.product.product_name %} will have a verified status. You can verify the signature locally using the public key available at `https://HOSTNAME/web-flow.gpg`. For more information, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/configuring-web-commit-signing)."
|
||||
{% else %}{% data variables.product.prodname_dotcom %} will automatically use GPG to sign commits you make using the web interface. Commits signed by {% data variables.product.prodname_dotcom %} will have a verified status. You can verify the signature locally using the public key available at https://github.com/web-flow.gpg. The full fingerprint of the key is `5DE3 E050 9C47 EA3C F04A 42D3 4AEE 18F8 3AFD EB23`.
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ When you synchronize license usage, only the user ID and email addresses for eac
|
||||
|
||||
You can use {% data variables.product.prodname_github_connect %} to automatically synchronize user license count and usage between {% data variables.product.prodname_ghe_server %} and {% data variables.product.prodname_ghe_cloud %} weekly. For more information, see "[Enabling automatic user license sync for your enterprise]({% ifversion ghec %}/enterprise-server@latest{% endif %}/admin/configuration/configuring-github-connect/enabling-automatic-user-license-sync-for-your-enterprise){% ifversion ghec %}" in the {% data variables.product.prodname_ghe_server %} documentation.{% elsif ghes %}."{% endif %}
|
||||
|
||||
{% ifversion ghec or ghes > 3.4 %}
|
||||
{% ifversion ghec or ghes %}
|
||||
After you enable {% data variables.product.prodname_github_connect %}, license data will be automatically synchronized weekly. You can also manually synchronize your license data at any time, by triggering a license sync job.
|
||||
|
||||
### Triggering a license sync job
|
||||
|
||||
@@ -29,18 +29,13 @@ By default, {% data variables.product.prodname_code_scanning %} analyzes your co
|
||||
|
||||
Each alert highlights a problem with the code and the name of the tool that identified it. You can see the line of code that triggered the alert, as well as properties of the alert, such as the alert severity, security severity, and the nature of the problem. Alerts also tell you when the issue was first introduced. For alerts identified by {% data variables.product.prodname_codeql %} analysis, you will also see information on how to fix the problem.
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
{% data reusables.code-scanning.alert-default-branch %}
|
||||
{% endif %}
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.8 %}
|
||||

|
||||
{% elsif ghes = 3.4 %}
|
||||

|
||||
{% else %}
|
||||

|
||||
{% endif %}
|
||||
|
||||
If you configure {% data variables.product.prodname_code_scanning %} using {% data variables.product.prodname_codeql %}, you can also find data-flow problems in your code. Data-flow analysis finds potential security issues in code, such as: using data insecurely, passing dangerous arguments to functions, and leaking sensitive information.
|
||||
|
||||
When {% data variables.product.prodname_code_scanning %} reports data-flow alerts, {% data variables.product.prodname_dotcom %} shows you how data moves through the code. {% data variables.product.prodname_code_scanning_caps %} allows you to identify the areas of your code that leak sensitive information, and that could be the entry point for attacks by malicious users.
|
||||
@@ -59,7 +54,6 @@ To calculate the security severity of an alert, we use Common Vulnerability Scor
|
||||
|
||||
By default, any {% data variables.product.prodname_code_scanning %} results with a security severity of `Critical` or `High` will cause a check failure. You can specify which security severity level for {% data variables.product.prodname_code_scanning %} results should cause a check failure. For more information, see "[AUTOTITLE](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/customizing-code-scanning#defining-the-severities-causing-pull-request-check-failure)."
|
||||
|
||||
{% ifversion fpt or ghes > 3.4 or ghae > 3.4 or ghec %}
|
||||
|
||||
### About {% ifversion remove-code-scanning-configurations %}alerts from multiple configurations{% else %}analysis origins{% endif %}
|
||||
|
||||
@@ -82,7 +76,6 @@ If you use multiple configurations to analyze a file, any problems detected by t
|
||||
|
||||
{% endnote %}
|
||||
{% endif %}
|
||||
{% endif %}
|
||||
|
||||
### About labels for alerts that are not found in application code
|
||||
|
||||
|
||||
@@ -36,10 +36,7 @@ You decide how to generate {% data variables.product.prodname_code_scanning %} a
|
||||
|
||||
{% data reusables.code-scanning.enabling-options %}
|
||||
|
||||
{% ifversion fpt or ghes > 3.4 or ghae > 3.4 or ghec %}
|
||||
{% data reusables.code-scanning.about-multiple-configurations-link %}
|
||||
{% endif %}
|
||||
|
||||
{% data reusables.code-scanning.codeql-action-version-ghes %}
|
||||
|
||||
{% ifversion code-scanning-tool-status-page %}
|
||||
@@ -262,38 +259,6 @@ The names of the {% data variables.product.prodname_code_scanning %} analysis ch
|
||||
|
||||
When the {% data variables.product.prodname_code_scanning %} jobs complete, {% data variables.product.prodname_dotcom %} works out whether any alerts were added by the pull request and adds the "{% data variables.product.prodname_code_scanning_caps %} results / TOOL NAME" entry to the list of checks. After {% data variables.product.prodname_code_scanning %} has been performed at least once, you can click **Details** to view the results of the analysis.
|
||||
|
||||
{% ifversion ghes < 3.5 %}
|
||||
If you used a pull request to add {% data variables.product.prodname_code_scanning %} to the repository, you will initially see an "Analysis not found" message when you click **Details** on the "{% data variables.product.prodname_code_scanning_caps %} results / TOOL NAME" check.
|
||||
|
||||

|
||||
|
||||
The table lists one or more categories. Each category relates to specific analyses, for the same tool and commit, performed on a different language or a different part of the code. For each category, the table shows the two analyses that {% data variables.product.prodname_code_scanning %} attempted to compare to determine which alerts were introduced or fixed in the pull request.
|
||||
|
||||
For example, in the screenshot above, {% data variables.product.prodname_code_scanning %} found an analysis for the merge commit of the pull request, but no analysis for the head of the main branch.
|
||||
|
||||
### Reasons for the "Analysis not found" message
|
||||
|
||||
After {% data variables.product.prodname_code_scanning %} has analyzed the code in a pull request, it needs to compare the analysis of the topic branch (the branch you used to create the pull request) with the analysis of the base branch (the branch into which you want to merge the pull request). This allows {% data variables.product.prodname_code_scanning %} to compute which alerts are newly introduced by the pull request, which alerts were already present in the base branch, and whether any existing alerts are fixed by the changes in the pull request. Initially, if you use a pull request to add {% data variables.product.prodname_code_scanning %} to a repository, the base branch has not yet been analyzed, so it's not possible to compute these details. In this case, when you click through from the results check on the pull request you will see the "Analysis not found" message.
|
||||
|
||||
There are other situations where there may be no analysis for the latest commit to the base branch for a pull request. These include:
|
||||
|
||||
- The pull request has been raised against a branch other than the default branch, and this branch hasn't been analyzed.
|
||||
|
||||
To check whether a branch has been scanned, go to the {% data variables.product.prodname_code_scanning_caps %} page, click the **Branch** drop-down and select the relevant branch.
|
||||
|
||||

|
||||
|
||||
The solution in this situation is to add the name of the base branch to the `on:push` and `on:pull_request` specification in the {% data variables.product.prodname_code_scanning %} workflow on that branch and then make a change that updates the open pull request that you want to scan.
|
||||
|
||||
- The latest commit on the base branch for the pull request is currently being analyzed and analysis is not yet available.
|
||||
|
||||
Wait a few minutes and then push a change to the pull request to retrigger {% data variables.product.prodname_code_scanning %}.
|
||||
|
||||
- An error occurred while analyzing the latest commit on the base branch and analysis for that commit isn't available.
|
||||
|
||||
Merge a trivial change into the base branch to trigger {% data variables.product.prodname_code_scanning %} on this latest commit, then push a change to the pull request to retrigger {% data variables.product.prodname_code_scanning %}.
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Next steps
|
||||
|
||||
|
||||
@@ -39,8 +39,7 @@ By default, the code scanning alerts page is filtered to show alerts for the def
|
||||
{% data reusables.repositories.sidebar-code-scanning-alerts %}
|
||||
1. Optionally, use the free text search box or the drop-down menus to filter alerts. For example, you can filter by the tool that was used to identify alerts.
|
||||
{% data reusables.code-scanning.explore-alert %}
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
{% data reusables.code-scanning.alert-default-branch %}{% endif %}
|
||||
{% data reusables.code-scanning.alert-default-branch %}
|
||||
1. Optionally, if the alert highlights a problem with data flow, click **Show paths** to display the path from the data source to the sink where it's used.
|
||||

|
||||
|
||||
@@ -74,9 +73,7 @@ When you select a keyword from either a drop-down list, or as you enter a keywor
|
||||
|
||||
If you enter multiple filters, the view will show alerts matching _all_ these filters. For example, `is:closed severity:high branch:main` will only display closed high-severity alerts that are present on the `main` branch. The exception is filters relating to refs (`ref`, `branch` and `pr`): `is:open branch:main branch:next` will show you open alerts from both the `main` branch and the `next` branch.
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
{% data reusables.code-scanning.filter-non-default-branches %}
|
||||
{% endif %}
|
||||
|
||||
{% ifversion fpt or ghes or ghec %}
|
||||
|
||||
@@ -143,11 +140,8 @@ Alerts may be fixed in one branch but not in another. You can use the "Branch" f
|
||||
|
||||

|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
{% data reusables.code-scanning.filter-non-default-branches %}
|
||||
{% endif %}
|
||||
|
||||
{% ifversion fpt or ghes > 3.4 or ghae > 3.4 or ghec %}
|
||||
{% note %}
|
||||
|
||||
**Note:**
|
||||
@@ -157,7 +151,6 @@ If you run {% data variables.product.prodname_code_scanning %} using multiple co
|
||||
If you run {% data variables.product.prodname_code_scanning %} using multiple configurations, then sometimes an alert will have multiple analysis origins. Unless you run all configurations regularly, you may see alerts that are fixed in one analysis origin but not in another. For more information, see "[AUTOTITLE](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning-alerts#about-analysis-origins)."
|
||||
{% endif %}
|
||||
{% endnote %}
|
||||
{% endif %}
|
||||
|
||||
## Dismissing {% ifversion delete-code-scanning-alerts %}or deleting{% endif %} alerts
|
||||
|
||||
|
||||
@@ -93,17 +93,11 @@ If you have write permission for the repository, some annotations contain links
|
||||
|
||||
To see more information about an alert, users with write permission can click the **Show more details** link shown in the annotation. This allows you to see all of the context and metadata provided by the tool in an alert view. In the example below, you can see tags showing the severity, type, and relevant common weakness enumerations (CWEs) for the problem. The view also shows which commit introduced the problem.
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
{% data reusables.code-scanning.alert-default-branch %}
|
||||
{% endif %}
|
||||
|
||||
In the detailed view for an alert, some {% data variables.product.prodname_code_scanning %} tools, like {% data variables.product.prodname_codeql %} analysis, also include a description of the problem and a **Show more** link for guidance on how to fix your code.
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||

|
||||
{% else %}
|
||||

|
||||
{% endif %}
|
||||
|
||||
{% ifversion code-scanning-pr-conversations-tab %}
|
||||
|
||||
|
||||
@@ -29,9 +29,7 @@ As an alternative to running {% data variables.product.prodname_code_scanning %}
|
||||
|
||||
If you use a third-party static analysis tool that can produce results as Static Analysis Results Interchange Format (SARIF) 2.1.0 data, you can upload this to {% data variables.product.prodname_dotcom %}. For more information, see "[AUTOTITLE](/code-security/code-scanning/integrating-with-code-scanning/uploading-a-sarif-file-to-github)."
|
||||
|
||||
{% ifversion fpt or ghes > 3.4 or ghae > 3.4 or ghec %}
|
||||
{% data reusables.code-scanning.about-multiple-configurations-link %}
|
||||
{% endif %}
|
||||
|
||||
## Integrations with webhooks
|
||||
|
||||
|
||||
@@ -34,9 +34,7 @@ redirect_from:
|
||||
|
||||
You add the {% data variables.product.prodname_codeql_cli %} to your third-party system, then call the tool to analyze code and upload the SARIF results to {% data variables.product.product_name %}. The resulting {% data variables.product.prodname_code_scanning %} alerts are shown alongside any alerts generated within {% data variables.product.product_name %}.
|
||||
|
||||
{% ifversion fpt or ghes > 3.4 or ghae > 3.4 or ghec %}
|
||||
{% data reusables.code-scanning.about-multiple-configurations-link %}
|
||||
{% endif %}
|
||||
|
||||
{% data reusables.code-scanning.upload-sarif-ghas %}
|
||||
|
||||
|
||||
@@ -26,7 +26,7 @@ topics:
|
||||
{% data reusables.dependabot.beta-security-and-version-updates %}
|
||||
{% data reusables.dependabot.enterprise-enable-dependabot %}
|
||||
|
||||
Your repository's {% data variables.product.prodname_dependabot_alerts %} tab lists all open and closed {% data variables.product.prodname_dependabot_alerts %}{% ifversion fpt or ghec or ghes %} and corresponding {% data variables.product.prodname_dependabot_security_updates %}{% endif %}. You can{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %} filter alerts by package, ecosystem, or manifest. You can {% endif %} sort the list of alerts, and you can click into specific alerts for more details. {% ifversion dependabot-bulk-alerts %}You can also dismiss or reopen alerts, either one by one or by selecting multiple alerts at once.{% else %}You can also dismiss or reopen alerts. {% endif %} For more information, see "[AUTOTITLE](/code-security/dependabot/dependabot-alerts/about-dependabot-alerts)."
|
||||
Your repository's {% data variables.product.prodname_dependabot_alerts %} tab lists all open and closed {% data variables.product.prodname_dependabot_alerts %}{% ifversion fpt or ghec or ghes %} and corresponding {% data variables.product.prodname_dependabot_security_updates %}{% endif %}. You can filter alerts by package, ecosystem, or manifest. You can sort the list of alerts, and you can click into specific alerts for more details. {% ifversion dependabot-bulk-alerts %}You can also dismiss or reopen alerts, either one by one or by selecting multiple alerts at once.{% else %}You can also dismiss or reopen alerts. {% endif %} For more information, see "[AUTOTITLE](/code-security/dependabot/dependabot-alerts/about-dependabot-alerts)."
|
||||
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
You can enable automatic security updates for any repository that uses {% data variables.product.prodname_dependabot_alerts %} and the dependency graph. For more information, see "[AUTOTITLE](/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates)."
|
||||
@@ -40,15 +40,13 @@ You can enable automatic security updates for any repository that uses {% data v
|
||||
|
||||
Each {% data variables.product.prodname_dependabot %} alert has a unique numeric identifier and the {% data variables.product.prodname_dependabot_alerts %} tab lists an alert for every detected vulnerability. Legacy {% data variables.product.prodname_dependabot_alerts %} grouped vulnerabilities by dependency and generated a single alert per dependency. If you navigate to a legacy {% data variables.product.prodname_dependabot %} alert, you will be redirected to a {% data variables.product.prodname_dependabot_alerts %} tab filtered for that package. {% endif %}
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
You can filter and sort {% data variables.product.prodname_dependabot_alerts %} using a variety of filters and sort options available on the user interface. For more information, see "[Prioritizing {% data variables.product.prodname_dependabot_alerts %}](#prioritizing-across--data-variablesproductprodname_dependabot_alerts-)" below.
|
||||
|
||||
You can also audit actions taken in response to {% data variables.product.prodname_dependabot %} alerts. For more information, see "[AUTOTITLE](/code-security/getting-started/auditing-security-alerts)."
|
||||
|
||||
## Prioritizing {% data variables.product.prodname_dependabot_alerts %}
|
||||
|
||||
{% data variables.product.company_short %} helps you prioritize fixing {% data variables.product.prodname_dependabot_alerts %}. {% ifversion dependabot-most-important-sort-option %} By default, {% data variables.product.prodname_dependabot_alerts %} are sorted by importance. The "Most important" sort order helps you prioritize which {% data variables.product.prodname_dependabot_alerts %} to focus on first. Alerts are ranked based on their potential impact, actionability, and relevance. Our prioritization calculation is constantly being improved and includes factors like CVSS score, dependency scope, and whether vulnerable function calls are found for the alert.{% endif %}
|
||||
|
||||
{% data variables.product.company_short %} helps you prioritize fixing {% data variables.product.prodname_dependabot_alerts %}. {% ifversion dependabot-most-important-sort-option %} By default, {% data variables.product.prodname_dependabot_alerts %} are sorted by importance. The "Most important" sort order helps you prioritize which {% data variables.product.prodname_dependabot_alerts %} to focus on first. Alerts are ranked based on their potential impact, actionability, and relevance. Our prioritization calculation is constantly being improved and includes factors like CVSS score, dependency scope, and whether vulnerable function calls are found for the alert.
|
||||
{% ifversion dependabot-alert-rules-auto-dismissal-npm-dev-dependencies %}
|
||||
You can also use alert rules to prioritize {% data variables.product.prodname_dependabot_alerts %}. For more information, see “[AUTOTITLE](/code-security/dependabot/dependabot-alerts/using-alert-rules-to-prioritize-dependabot-alerts).”
|
||||
{% endif %}
|
||||
@@ -114,7 +112,6 @@ For more information, see "[Reviewing and fixing alerts](#reviewing-and-fixing-a
|
||||
|
||||
## Viewing {% data variables.product.prodname_dependabot_alerts %}
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-security %}
|
||||
{% data reusables.repositories.sidebar-dependabot-alerts %}
|
||||
@@ -123,10 +120,6 @@ For more information, see "[Reviewing and fixing alerts](#reviewing-and-fixing-a
|
||||
{%- ifversion dependabot-bulk-alerts %}
|
||||
{% endif %}
|
||||
1. Click the alert that you would like to view.
|
||||
{% else %}
|
||||
{% data reusables.dependabot.navigate-to-dependabot-alerts %}
|
||||
1. Click the alert you'd like to view.
|
||||
{% endif %}
|
||||
{% ifversion dependabot-filter-label-security-advisory %}
|
||||
1. Optionally, to suggest an improvement to the related security advisory, on the right-hand side of the alert details page, click **Suggest improvements for this advisory on the {% data variables.product.prodname_advisory_database %}**. For more information, see "[AUTOTITLE](/code-security/security-advisories/global-security-advisories/editing-security-advisories-in-the-github-advisory-database)."
|
||||
|
||||
|
||||
@@ -60,7 +60,7 @@ If you've enabled security updates, you'll sometimes see extra pull requests for
|
||||
|
||||
You can configure version updates for repositories that contain a dependency manifest or lock file for one of the supported package managers. For some package managers, you can also configure vendoring for dependencies. For more information, see "[AUTOTITLE](/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#vendor)."
|
||||
|
||||
{% ifversion ghes > 3.4 %}
|
||||
{% ifversion ghes %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
||||
@@ -68,7 +68,7 @@ In general, security updates use any configuration options that affect pull requ
|
||||
|
||||
### `package-ecosystem`
|
||||
|
||||
**Required**. You add one `package-ecosystem` element for each package manager that you want {% data variables.product.prodname_dependabot %} to monitor for new versions. The repository must also contain a dependency manifest or lock file for each of these package managers. If you want to enable vendoring for a package manager that supports it, the vendored dependencies must be located in the required directory. For more information, see [`vendor`](#vendor) below.{% ifversion ghes > 3.4 %}
|
||||
**Required**. You add one `package-ecosystem` element for each package manager that you want {% data variables.product.prodname_dependabot %} to monitor for new versions. The repository must also contain a dependency manifest or lock file for each of these package managers. If you want to enable vendoring for a package manager that supports it, the vendored dependencies must be located in the required directory. For more information, see [`vendor`](#vendor) below.{% ifversion ghes %}
|
||||
|
||||
{% note %}
|
||||
|
||||
@@ -378,7 +378,7 @@ updates:
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
{% note %}
|
||||
|
||||
**Note**: For the `pub` ecosystem, {% data variables.product.prodname_dependabot %} won't perform an update when the version that it tries to update to is ignored, even if an earlier version is available.
|
||||
@@ -1248,7 +1248,7 @@ registries:
|
||||
|
||||
{% endraw %}
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
|
||||
## Enabling support for beta-level ecosystems
|
||||
|
||||
|
||||
@@ -125,7 +125,7 @@ Show the full impact of changes to dependencies and see details of any vulnerabl
|
||||
|
||||
{% else %}
|
||||
|
||||
### Security overview for organizations{% ifversion ghes > 3.4 or ghae > 3.4 %}, enterprises,{% endif %} and teams
|
||||
### Security overview for organizations{% ifversion ghes or ghae %}, enterprises,{% endif %} and teams
|
||||
|
||||
Review the security configuration and alerts for your organization and identify the repositories at greatest risk. For more information, see "[AUTOTITLE](/code-security/security-overview/about-security-overview)."
|
||||
{% endif %}
|
||||
|
||||
@@ -26,7 +26,7 @@ topics:
|
||||
|
||||
If your project communicates with an external service, you might use a token or private key for authentication. Tokens and private keys are examples of secrets that a service provider can issue. If you check a secret into a repository, anyone who has read access to the repository can use the secret to access the external service with your privileges. We recommend that you store secrets in a dedicated, secure location outside of the repository for your project.
|
||||
|
||||
{% data variables.product.prodname_secret_scanning_caps %} will scan your entire Git history on all branches present in your {% data variables.product.prodname_dotcom %} repository for secrets{% ifversion ghec or ghes > 3.4 or ghae > 3.4 %}, even if the repository is archived{% endif %}. {% ifversion secret-scanning-issue-body-comments %}{% data reusables.secret-scanning.scan-issue-description-and-comments %}{% endif %}
|
||||
{% data variables.product.prodname_secret_scanning_caps %} will scan your entire Git history on all branches present in your {% data variables.product.prodname_dotcom %} repository for secrets{% ifversion ghec or ghes or ghae %}, even if the repository is archived{% endif %}. {% ifversion secret-scanning-issue-body-comments %}{% data reusables.secret-scanning.scan-issue-description-and-comments %}{% endif %}
|
||||
|
||||
{% ifversion secret-scanning-backfills-historical-issues %}
|
||||
{% data variables.product.prodname_secret_scanning_caps %} also scans the titles, descriptions, and comments, in open and closed historical issues, and reports leaked secrets as alerts on {% data variables.product.prodname_dotcom %}{% ifversion ghec %}. A notification is sent to the relevant partner when a historical partner pattern is detected{% endif %}.
|
||||
@@ -83,7 +83,7 @@ You cannot change the configuration of {% data variables.product.prodname_secret
|
||||
{% endnote %}
|
||||
{% endif %}
|
||||
|
||||
If you're a repository administrator, you can enable {% data variables.secret-scanning.user_alerts %} for any {% ifversion fpt %}public{% endif %} repository{% ifversion ghec or ghes > 3.4 or ghae > 3.4 %}, including archived repositories{% endif %}. Organization owners can also enable {% data variables.secret-scanning.user_alerts %} for all {% ifversion fpt %}public {% endif %}repositories or for all new {% ifversion fpt %}public {% endif %}repositories within an organization. For more information, see "[AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-security-and-analysis-settings-for-your-repository)" and "[AUTOTITLE](/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/managing-security-and-analysis-settings-for-your-organization)."
|
||||
If you're a repository administrator, you can enable {% data variables.secret-scanning.user_alerts %} for any {% ifversion fpt %}public{% endif %} repository{% ifversion ghec or ghes or ghae %}, including archived repositories{% endif %}. Organization owners can also enable {% data variables.secret-scanning.user_alerts %} for all {% ifversion fpt %}public {% endif %}repositories or for all new {% ifversion fpt %}public {% endif %}repositories within an organization. For more information, see "[AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-security-and-analysis-settings-for-your-repository)" and "[AUTOTITLE](/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/managing-security-and-analysis-settings-for-your-organization)."
|
||||
|
||||
You can also define custom {% data variables.product.prodname_secret_scanning %} patterns for a repository, organization, or enterprise. For more information, see "[AUTOTITLE]({% ifversion fpt %}/enterprise-cloud@latest{% endif %}/code-security/secret-scanning/defining-custom-patterns-for-secret-scanning){% ifversion fpt %}" in the {% data variables.product.prodname_ghe_cloud %} documentation.{% else %}."{% endif %}
|
||||
|
||||
|
||||
@@ -97,7 +97,7 @@ aAAAe9
|
||||
|
||||
Before defining a custom pattern, you must ensure that you enable {% data variables.product.prodname_secret_scanning %} for the repositories that you want to scan in your organization. To enable {% data variables.product.prodname_secret_scanning %} on all repositories in your organization, see "[AUTOTITLE](/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/managing-security-and-analysis-settings-for-your-organization)."
|
||||
|
||||
{% ifversion ghes < 3.5 or ghae %}
|
||||
{% ifversion ghae %}
|
||||
{% note %}
|
||||
|
||||
**Note:** As there is no dry-run functionality, we recommend that you test your custom patterns in a repository before defining them for your entire organization. That way, you can avoid creating excess false-positive {% data variables.secret-scanning.alerts %}.
|
||||
|
||||
@@ -105,17 +105,6 @@ This table lists the secrets supported by {% data variables.product.prodname_sec
|
||||
{%- endfor %}
|
||||
{% endif %}
|
||||
|
||||
<!-- GHES 3.4 version of table -->
|
||||
{% ifversion ghes = 3.4 %}
|
||||
|
||||
| Provider | Token | {% data variables.product.prodname_secret_scanning_caps %} alert |
|
||||
|----|:----|:----:|
|
||||
{%- for entry in secretScanningData %}
|
||||
| {{ entry.provider }} | {{ entry.secretType }} | {% if entry.isPrivateWithGhas %}{% octicon "check" aria-label="Supported" %}{% else %}{% octicon "x" aria-label="Unsupported" %}{% endif %} |
|
||||
{%- endfor %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
<!-- GHES 3.5 to GHES 3.8 table -->
|
||||
{% ifversion ghes = 3.5 or ghes = 3.6 or ghes = 3.7 or ghes = 3.8 %}
|
||||
|
||||
|
||||
@@ -24,7 +24,7 @@ topics:
|
||||
shortTitle: Security overview
|
||||
---
|
||||
|
||||
{% ifversion ghes < 3.5 or ghae %}
|
||||
{% ifversion ghae %}
|
||||
{% data reusables.security-overview.beta %}
|
||||
{% endif %}
|
||||
|
||||
@@ -86,7 +86,7 @@ Each repository is shown in security overview with an indicator for each type of
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% ifversion ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
{% ifversion ghec or ghes or ghae %}
|
||||
|
||||
## About security overview for enterprises
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ intro: 'You can use security overview to see which teams and repositories are af
|
||||
permissions: '{% data reusables.security-overview.permissions %}'
|
||||
product: '{% data reusables.gated-features.security-overview %}'
|
||||
type: how_to
|
||||
topics:
|
||||
topics:
|
||||
- Security overview
|
||||
- Advanced Security
|
||||
- Alerts
|
||||
@@ -20,7 +20,7 @@ redirect_from:
|
||||
- /code-security/security-overview/viewing-the-security-overview
|
||||
---
|
||||
|
||||
{% ifversion ghes < 3.5 or ghae %}
|
||||
{% ifversion ghae %}
|
||||
{% data reusables.security-overview.beta %}
|
||||
{% endif %}
|
||||
|
||||
@@ -66,7 +66,7 @@ You can use security overview to see which repositories and teams are free from
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% ifversion ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
{% ifversion ghec or ghes or ghae %}
|
||||
|
||||
## Viewing enterprise-level code security risks
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Enabling security features for multiple repositories
|
||||
shortTitle: Enable security features
|
||||
intro: 'You can use security overview to select a subset of repositories and enable security features for them all.'
|
||||
intro: You can use security overview to select a subset of repositories and enable security features for them all.
|
||||
permissions: '{% data reusables.security-overview.permissions %}'
|
||||
product: '{% data reusables.gated-features.security-overview %}'
|
||||
allowTitleToDifferFromFilename: true
|
||||
@@ -16,7 +16,7 @@ topics:
|
||||
- Teams
|
||||
---
|
||||
|
||||
{% ifversion ghes < 3.5 or ghae %}
|
||||
{% ifversion ghae %}
|
||||
{% data reusables.security-overview.beta %}
|
||||
{% endif %}
|
||||
|
||||
|
||||
@@ -20,13 +20,13 @@ redirect_from:
|
||||
- /code-security/security-overview/filtering-alerts-in-the-security-overview
|
||||
---
|
||||
|
||||
{% ifversion ghes < 3.5 or ghae %}
|
||||
{% ifversion ghae %}
|
||||
{% data reusables.security-overview.beta %}
|
||||
{% endif %}
|
||||
|
||||
## About filtering security overview
|
||||
|
||||
You can use filters in a security overview to narrow your focus based on a range of factors, like alert risk level, alert type, and feature enablement. Different filters are available depending on the specific view{% ifversion ghec or ghes > 3.4 or ghae > 3.4 %} and whether you are viewing data at the enterprise or organization level{% endif %}.
|
||||
You can use filters in a security overview to narrow your focus based on a range of factors, like alert risk level, alert type, and feature enablement. Different filters are available depending on the specific view{% ifversion ghec or ghes or ghae %} and whether you are viewing data at the enterprise or organization level{% endif %}.
|
||||
|
||||
{% ifversion security-overview-displayed-alerts %}
|
||||
{% note %}
|
||||
|
||||
@@ -3,8 +3,8 @@ title: Creating a branch to work on an issue
|
||||
intro: You can create a branch to work on an issue directly from the issue page and get started right away.
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '>=3.5'
|
||||
ghae: '>= 3.5'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
allowTitleToDifferFromFilename: true
|
||||
topics:
|
||||
|
||||
@@ -69,11 +69,7 @@ You can manually link up to ten issues to each pull request. The issue and pull
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
1. In the list of pull requests, click the pull request that you'd like to link to an issue.
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
{% data reusables.pull_requests.click-development %}
|
||||
{% else %}
|
||||
1. In the right sidebar, click **Linked issues**.
|
||||
{% endif %}
|
||||
1. Click the issue you want to link to the pull request.
|
||||
|
||||
{% ifversion link-existing-branches-to-issue %}
|
||||
|
||||
@@ -29,9 +29,7 @@ When {% data variables.projects.projects_v1_boards %} are disabled, you will no
|
||||
|
||||
{% data reusables.profile.access_org %}
|
||||
{% data reusables.profile.org_settings %}
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
1. In the "Code planning, and automation" section of the sidebar, click **{% octicon "table" aria-label="The table icon" %} Projects**.
|
||||
{% endif %}
|
||||
1. Decide whether to disable {% data variables.projects.projects_v2_and_v1 %} in your organization. Then, under **Projects{% ifversion ghes = 3.7 %} (classic){% endif %}**:
|
||||
- To disable {% data variables.projects.projects_v2_and_v1 %}, unselect **Enable Projects{% ifversion ghes = 3.7 %} (classic){% endif %} for the organization**.
|
||||
- To enable {% data variables.projects.projects_v2_and_v1 %} in the organization, select **Enable Projects{% ifversion ghes = 3.7 %} (classic){% endif %} for the organization**.
|
||||
@@ -47,9 +45,7 @@ You can control whether organization members can create {% data variables.projec
|
||||
|
||||
{% data reusables.profile.access_org %}
|
||||
{% data reusables.profile.org_settings %}
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
1. In the "Code planning, and automation" section of the sidebar, click **{% octicon "table" aria-label="The table icon" %} Projects**.
|
||||
{% endif %}
|
||||
1. Decide whether to allow members to create {% data variables.projects.projects_v1_boards %} in repositories in your organization. Then, under **{%ifversion ghes > 3.7 or ghae > 3.7 or ghec or fpt %}Projects (classic) only{% elsif ghes = 3.7 %}Repository projects{% else %}Projects{% endif %}**:
|
||||
- To enable project boards in repositories, select **{% ifversion ghes < 3.7 %}Enable projects for all repositories{% else %}Allow members to enable Projects (classic) for all repositories{% endif %}**.
|
||||
- To disable project boards in repositories, unselect **{% ifversion ghes < 3.7 %}Enable projects for all repositories{% else %}Allow members to enable Projects (classic) for all repositories{% endif %}**.
|
||||
|
||||
@@ -10,7 +10,7 @@ versions:
|
||||
shortTitle: Integrate Jira
|
||||
---
|
||||
|
||||
{% ifversion ghes > 3.4 or ghae > 3.4 %}
|
||||
{% ifversion ghes or ghae %}
|
||||
{% data reusables.profile.access_org %}
|
||||
{% data reusables.profile.org_settings %}
|
||||
1. In the left sidebar, select **{% octicon "code" aria-hidden="true" %} Developer settings**, then click **OAuth Apps**.
|
||||
|
||||
@@ -31,7 +31,7 @@ From least access to most access, the roles for an organization repository are:
|
||||
|
||||
{% ifversion fpt %}
|
||||
If your organization uses {% data variables.product.prodname_ghe_cloud %}, you can create custom repository roles. For more information, see "[AUTOTITLE](/enterprise-cloud@latest/organizations/managing-peoples-access-to-your-organization-with-roles/managing-custom-repository-roles-for-an-organization)" in the {% data variables.product.prodname_ghe_cloud %} documentation.
|
||||
{% elsif ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
{% elsif ghec or ghes or ghae %}
|
||||
You can create custom repository roles. For more information, see "[AUTOTITLE](/organizations/managing-peoples-access-to-your-organization-with-roles/managing-custom-repository-roles-for-an-organization)."
|
||||
{% endif %}
|
||||
|
||||
@@ -113,9 +113,9 @@ Some of the features listed below are limited to organizations using {% data var
|
||||
| Manage [branch protection rules](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule){% ifversion repo-rules %} and [repository rulesets](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets){% endif %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "check" aria-label="Yes" %} |{% ifversion repo-rules %}
|
||||
| View [rulesets for a repository](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets) | {% octicon "check" aria-label="Yes" %} | {% octicon "check" aria-label="Yes" %} | {% octicon "check" aria-label="Yes" %} | {% octicon "check" aria-label="Yes" %} | {% octicon "check" aria-label="Yes" %} |
|
||||
{% endif %}| [Push to protected branches](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "check" aria-label="Yes" %} | {% octicon "check" aria-label="Yes" %} |
|
||||
| Merge pull requests on protected branches, even if there are no approving reviews | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "check" aria-label="Yes" %} |{% ifversion fpt or ghes > 3.4 or ghae > 3.4 or ghec %}
|
||||
| Merge pull requests on protected branches, even if there are no approving reviews | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "check" aria-label="Yes" %} |
|
||||
| Create tags that match a [tag protection rule](/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/configuring-tag-protection-rules) | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "check" aria-label="Yes" %} | {% octicon "check" aria-label="Yes" %} |
|
||||
| Delete tags that match a [tag protection rule](/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/configuring-tag-protection-rules) | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "check" aria-label="Yes" %} |{% endif %}
|
||||
| Delete tags that match a [tag protection rule](/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/configuring-tag-protection-rules) | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "check" aria-label="Yes" %} |
|
||||
| [Create and edit repository social cards](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/customizing-your-repositorys-social-media-preview) | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "check" aria-label="Yes" %} | {% octicon "check" aria-label="Yes" %} |{% ifversion fpt or ghec %}
|
||||
| Limit [interactions in a repository](/communities/moderating-comments-and-conversations/limiting-interactions-in-your-repository)| {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "check" aria-label="Yes" %} | {% octicon "check" aria-label="Yes" %} |{% endif %}
|
||||
| Delete an issue (see "[AUTOTITLE](/issues/tracking-your-work-with-issues/deleting-an-issue)") | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "check" aria-label="Yes" %} |
|
||||
|
||||
@@ -55,11 +55,7 @@ Any team members that have set their status to "Busy" will not be selected for r
|
||||
{% data reusables.user-settings.access_org %}
|
||||
{% data reusables.organizations.specific_team %}
|
||||
{% data reusables.organizations.team_settings %}
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
1. In the left sidebar, click **{% octicon "code-review" aria-hidden="true" %} Code review**.
|
||||
{% else %}
|
||||
1. In the left sidebar, click **Code review**
|
||||
{% endif %}
|
||||
1. Select **Only notify requested team members.**
|
||||
1. Click **Save changes**.
|
||||
{% endif %}
|
||||
@@ -70,11 +66,7 @@ Any team members that have set their status to "Busy" will not be selected for r
|
||||
{% data reusables.user-settings.access_org %}
|
||||
{% data reusables.organizations.specific_team %}
|
||||
{% data reusables.organizations.team_settings %}
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
1. In the left sidebar, click **{% octicon "code-review" aria-hidden="true" %} Code review**.
|
||||
{% else %}
|
||||
1. In the left sidebar, click **Code review**
|
||||
{% endif %}
|
||||
1. Select **Enable auto assignment**.
|
||||
1. Under "How many team members should be assigned to review?", select the dropdown menu and choose a number of reviewers to be assigned to each pull request.
|
||||
1. Under "Routing algorithm", use the dropdown menu and choose which algorithm you'd like to use. For more information, see "[Routing algorithms](#routing-algorithms)."
|
||||
|
||||
@@ -26,13 +26,13 @@ When you publish a package that is scoped to a personal account or an organizati
|
||||
1. Search for and then click the name of the package that you want to manage.
|
||||
{% data reusables.package_registry.repository_connection_steps %}
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
|
||||
## Connecting a repository to a container image using the command line
|
||||
|
||||
{% data reusables.package_registry.auto-inherit-permissions-note %}
|
||||
|
||||
{% ifversion ghes > 3.4 %}
|
||||
{% ifversion ghes %}
|
||||
{% data reusables.package_registry.container-registry-ghes-beta %}
|
||||
{% endif %}
|
||||
|
||||
@@ -42,7 +42,7 @@ When you publish a package that is scoped to a personal account or an organizati
|
||||
LABEL org.opencontainers.image.source=https://{% ifversion fpt or ghec %}github.com{% else %}HOSTNAME{% endif %}/OWNER/REPO
|
||||
```
|
||||
|
||||
For example, if you're the user `octocat` and own `my-repo`{% ifversion ghes > 3.4 %}, and your {% data variables.location.product_location %} hostname is `github.companyname.com`,{% endif %} you would add this line to your Dockerfile:
|
||||
For example, if you're the user `octocat` and own `my-repo`{% ifversion ghes %}, and your {% data variables.location.product_location %} hostname is `github.companyname.com`,{% endif %} you would add this line to your Dockerfile:
|
||||
|
||||
```shell
|
||||
LABEL org.opencontainers.image.source=https://{% ifversion fpt or ghec %}github.com{% else %}{% data reusables.package_registry.container-registry-example-hostname %}{% endif %}/octocat/my-repo
|
||||
@@ -77,7 +77,7 @@ When you publish a package that is scoped to a personal account or an organizati
|
||||
For example:
|
||||
|
||||
```shell
|
||||
docker tag 38f737a91f39 {% ifversion fpt or ghec %}ghcr.io{% elsif ghes > 3.4 %}{% data reusables.package_registry.container-registry-example-hostname %}{% endif %}/octocat/hello_docker:latest
|
||||
docker tag 38f737a91f39 {% ifversion fpt or ghec %}ghcr.io{% elsif ghes %}{% data reusables.package_registry.container-registry-example-hostname %}{% endif %}/octocat/hello_docker:latest
|
||||
```
|
||||
|
||||
1. If you haven't already, authenticate to the {% data variables.product.prodname_container_registry %}. For more information, see "[AUTOTITLE](/packages/working-with-a-github-packages-registry/working-with-the-container-registry#authenticating-to-the-container-registry)."
|
||||
@@ -98,7 +98,7 @@ When you publish a package that is scoped to a personal account or an organizati
|
||||
For example:
|
||||
|
||||
```shell
|
||||
docker push {% ifversion fpt or ghec %}ghcr.io{% elsif ghes > 3.4 %}{% data reusables.package_registry.container-registry-example-hostname %}{% endif %}/octocat/hello_docker:latest
|
||||
docker push {% ifversion fpt or ghec %}ghcr.io{% elsif ghes %}{% data reusables.package_registry.container-registry-example-hostname %}{% endif %}/octocat/hello_docker:latest
|
||||
```
|
||||
|
||||
{% endif %}
|
||||
|
||||
@@ -25,7 +25,7 @@ shortTitle: Container registry
|
||||
|
||||
{% data reusables.package_registry.container-registry-benefits %}
|
||||
|
||||
{% ifversion ghes > 3.4 %}
|
||||
{% ifversion ghes %}
|
||||
|
||||
To use the {% data variables.product.prodname_container_registry %} on {% data variables.product.product_name %}, your site administrator must first configure {% data variables.product.prodname_registry %} for your instance **and** enable subdomain isolation. For more information, see "[AUTOTITLE](/admin/packages/getting-started-with-github-packages-for-your-enterprise)" and "[AUTOTITLE](/admin/configuration/configuring-network-settings/enabling-subdomain-isolation)."
|
||||
|
||||
@@ -77,7 +77,7 @@ docker push {% data reusables.package_registry.container-registry-hostname %}/NA
|
||||
|
||||
{% data reusables.package_registry.publishing-user-scoped-packages %} You can link a published package to a repository using the user interface or command line. For more information, see "[AUTOTITLE](/packages/learn-github-packages/connecting-a-repository-to-a-package)."
|
||||
|
||||
When you push a container image from the command line, the image is not linked to a repository by default. This is the case even if you tag the image with a namespace that matches the name of the repository, such as `{% ifversion fpt or ghec %}ghcr.io{% elsif ghes > 3.4 %}{% data reusables.package_registry.container-registry-example-hostname %}{% endif %}/octocat/my-repo:latest`.
|
||||
When you push a container image from the command line, the image is not linked to a repository by default. This is the case even if you tag the image with a namespace that matches the name of the repository, such as `{% ifversion fpt or ghec %}ghcr.io{% elsif ghes %}{% data reusables.package_registry.container-registry-example-hostname %}{% endif %}/octocat/my-repo:latest`.
|
||||
|
||||
The easiest way to connect a repository to a container package is to publish the package from a workflow using `${% raw %}{{secrets.GITHUB_TOKEN}}{% endraw %}`, as the repository that contains the workflow is linked automatically. Note that the `GITHUB_TOKEN` will not have permission to push the package if you have previously pushed a package to the same namespace, but have not connected the package to the repository.
|
||||
|
||||
|
||||
@@ -59,7 +59,7 @@ You can create a branch in different ways on {% data variables.product.product_n
|
||||
|
||||

|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
|
||||
### Creating a branch for an issue
|
||||
|
||||
|
||||
@@ -20,25 +20,18 @@ You can update a pull request's head branch from the command line or the pull re
|
||||
|
||||
- There are no merge conflicts between the pull request branch and the base branch.
|
||||
- The pull request branch is not up to date with the base branch.
|
||||
- The base branch requires branches to be up to date before merging{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %} or the setting to always suggest updating branches is enabled{% endif %}.
|
||||
- The base branch requires branches to be up to date before merging or the setting to always suggest updating branches is enabled.
|
||||
|
||||
For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches){% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}" and "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-suggestions-to-update-pull-request-branches){% endif %}."
|
||||
For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)" and "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-suggestions-to-update-pull-request-branches)."
|
||||
|
||||
If there are changes to the base branch that cause merge conflicts in your pull request branch, you will not be able to update the branch until all conflicts are resolved. For more information, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/about-merge-conflicts)."
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
From the pull request page you can update your pull request's branch using a traditional merge or by rebasing. A traditional merge results in a merge commit that merges the base branch into the head branch of the pull request. Rebasing applies the changes from _your_ branch onto the latest version of the base branch. The result is a branch with a linear history, since no merge commit is created.
|
||||
{% else %}
|
||||
Updating your branch from the pull request page performs a traditional merge. The resulting merge commit merges the base branch into the head branch of the pull request.
|
||||
{% endif %}
|
||||
|
||||
## Updating your pull request branch
|
||||
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
|
||||
1. In the "Pull requests" list, click the pull request you'd like to update.
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
1. In the merge section near the bottom of the page, you can:
|
||||
- Click **Update branch** to perform a traditional merge.
|
||||
|
||||
@@ -47,11 +40,6 @@ Updating your branch from the pull request page performs a traditional merge. Th
|
||||
- Click the update branch drop down menu, click **Update with rebase**, and then click **Rebase branch** to update by rebasing on the base branch.
|
||||
|
||||

|
||||
{% else %}
|
||||
1. In the merge section near the bottom of the page, click **Update branch** to perform a traditional merge.
|
||||
|
||||

|
||||
{% endif %}
|
||||
|
||||
## Further reading
|
||||
|
||||
|
||||
@@ -27,7 +27,7 @@ topics:
|
||||
{% endnote %}
|
||||
{% endif %}
|
||||
|
||||
{% ifversion ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
{% ifversion ghec or ghes or ghae %}
|
||||
{% note %}
|
||||
|
||||
**Note:** Customers who use {% data variables.product.prodname_GH_advanced_security %} can enable {% data variables.product.prodname_secret_scanning %} on archived repositories. For more information, see "[AUTOTITLE](/code-security/secret-scanning/about-secret-scanning#about-secret-scanning-for-private-repositories)."
|
||||
|
||||
@@ -25,4 +25,4 @@ If you allow auto-merge for pull requests in your repository, people with write
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
1. Under {% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}"Pull Requests"{% else %}"Merge button"{% endif %}, select or deselect **Allow auto-merge**.
|
||||
1. Under "Pull Requests", select or deselect **Allow auto-merge**.
|
||||
|
||||
@@ -18,7 +18,7 @@ Anyone with admin permissions to a repository can enable or disable the automati
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
1. Under {% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}"Pull Requests"{% else %}"Merge button"{% endif %}, select or unselect **Automatically delete head branches**.
|
||||
1. Under "Pull Requests", select or unselect **Automatically delete head branches**.
|
||||
|
||||
## Further reading
|
||||
|
||||
|
||||
@@ -137,8 +137,8 @@ You can use the steps below to configure whether {% ifversion internal-actions%}
|
||||
1. Under **Access**, choose one of the access settings:
|
||||
|
||||
- **Not accessible** - Workflows in other repositories cannot access this repository.
|
||||
- **Accessible from repositories in the 'ORGANIZATION NAME' organization** - {% ifversion ghes > 3.4 or ghae > 3.4 or ghec %}Workflows in other repositories that are part of the 'ORGANIZATION NAME' organization can access the actions and reusable workflows in this repository. Access is allowed only from private or internal repositories.{% else %}Workflows in other repositories can use workflows in this repository if they are part of the same organization and their visibility is private or internal.{% endif %}
|
||||
- **Accessible from repositories in the 'ENTERPRISE NAME' enterprise** - {% ifversion ghes > 3.4 or ghae > 3.4 or ghec %}Workflows in other repositories that are part of the 'ENTERPRISE NAME' enterprise can access the actions and reusable workflows in this repository. Access is allowed only from private or internal repositories.{% else %}Workflows in other repositories can use workflows in this repository if they are part of the same enterprise and their visibility is private or internal.{% endif %}
|
||||
- **Accessible from repositories in the 'ORGANIZATION NAME' organization** - {% ifversion ghes or ghae or ghec %}Workflows in other repositories that are part of the 'ORGANIZATION NAME' organization can access the actions and reusable workflows in this repository. Access is allowed only from private or internal repositories.{% else %}Workflows in other repositories can use workflows in this repository if they are part of the same organization and their visibility is private or internal.{% endif %}
|
||||
- **Accessible from repositories in the 'ENTERPRISE NAME' enterprise** - {% ifversion ghes or ghae or ghec %}Workflows in other repositories that are part of the 'ENTERPRISE NAME' enterprise can access the actions and reusable workflows in this repository. Access is allowed only from private or internal repositories.{% else %}Workflows in other repositories can use workflows in this repository if they are part of the same enterprise and their visibility is private or internal.{% endif %}
|
||||
1. Click **Save** to apply the settings.
|
||||
{% endif %}
|
||||
|
||||
|
||||
@@ -34,11 +34,7 @@ This procedure demonstrates how to configure autolinks to reference external res
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
1. In the "Integrations" section of the sidebar, click **{% octicon "cross-reference" aria-hidden="true" %} Autolink references**.
|
||||
{% else %}
|
||||
1. In the left sidebar, click **Autolink references**.
|
||||
{% endif %}
|
||||
1. At the top right of the page, click **Add autolink reference**.
|
||||
|
||||

|
||||
|
||||
@@ -5,9 +5,9 @@ intro: You can configure tag protection rules for your repository to prevent con
|
||||
product: '{% data reusables.gated-features.tag-protection-rules %}'
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghae: '>= 3.5'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
ghes: '>3.4'
|
||||
ghes: '*'
|
||||
---
|
||||
|
||||
{% note %}
|
||||
|
||||
@@ -32,33 +32,21 @@ For more information about repository roles, see "[AUTOTITLE](/account-and-profi
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
{% data reusables.repositories.click-collaborators-teams %}
|
||||
{% else %}
|
||||
{% data reusables.repositories.navigate-to-manage-access %}
|
||||
{% endif %}
|
||||
1. Under "Manage access", in the search field, start typing the name of the team or person you'd like to find. Optionally, use the dropdown menus to filter your search.
|
||||
|
||||
## Changing permissions for a team or person
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
{% data reusables.repositories.click-collaborators-teams %}
|
||||
{% else %}
|
||||
{% data reusables.repositories.navigate-to-manage-access %}
|
||||
{% endif %}
|
||||
1. Under "Manage access", next to the team or person whose role you'd like to change, select the **Role** dropdown menu, and click a new role.
|
||||
|
||||
## Inviting a team or person
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
{% data reusables.repositories.click-collaborators-teams %}
|
||||
{% else %}
|
||||
{% data reusables.repositories.navigate-to-manage-access %}
|
||||
{% endif %}
|
||||
{% data reusables.organizations.invite-teams-or-people %}
|
||||
1. In the search field, start typing the name of the team or person to invite, then click a name in the list of matches.
|
||||
1. Under "Choose a role", select the repository role to grant to the team or person, then click **Add NAME to REPOSITORY**.
|
||||
@@ -67,11 +55,7 @@ For more information about repository roles, see "[AUTOTITLE](/account-and-profi
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
{% data reusables.repositories.click-collaborators-teams %}
|
||||
{% else %}
|
||||
{% data reusables.repositories.navigate-to-manage-access %}
|
||||
{% endif %}
|
||||
1. Under "Manage access", next to the team or person whose access you'd like to remove, click **Remove**.
|
||||
|
||||
## Further reading
|
||||
|
||||
@@ -1,9 +1,5 @@
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** To enhance security, {% data variables.product.prodname_actions %} does not support redirects for actions or reusable workflows. This means that when the owner, name of an action's repository, or name of an action is changed, any workflows using that action with the previous name will fail.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
@@ -1,8 +1,4 @@
|
||||
If you plan to enable {% data variables.product.prodname_actions %} for the users of your instance, more resources are required. {%- ifversion ghes = 3.4 %}
|
||||
|
||||
{% data reusables.actions.hardware-requirements-3.4 %}
|
||||
|
||||
{%- endif %}
|
||||
If you plan to enable {% data variables.product.prodname_actions %} for the users of your instance, more resources are required.
|
||||
{%- ifversion ghes = 3.5 %}
|
||||
|
||||
{% data reusables.actions.hardware-requirements-3.5 %}
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
- `{owner}/{repo}/.github/workflows/{filename}@{ref}`{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %} for reusable workflows in {% ifversion fpt %}public and private{% elsif ghec or ghes > 3.7 or ghae > 3.7 %}public, internal and private{% else %}public and internal{% endif %} repositories.
|
||||
- `./.github/workflows/{filename}` for reusable workflows in the same repository.{% endif %}
|
||||
- `{owner}/{repo}/.github/workflows/{filename}@{ref}` for reusable workflows in {% ifversion fpt %}public and private{% elsif ghec or ghes > 3.7 or ghae > 3.7 %}public, internal and private{% else %}public and internal{% endif %} repositories.
|
||||
- `./.github/workflows/{filename}` for reusable workflows in the same repository.
|
||||
|
||||
`{ref}` can be a SHA, a release tag, or a branch name. Using the commit SHA is the safest for stability and security. For more information, see "[AUTOTITLE](/actions/security-guides/security-hardening-for-github-actions#reusing-third-party-workflows)."{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %} If you use the second syntax option (without `{owner}/{repo}` and `@{ref}`) the called workflow is from the same commit as the caller workflow.{% endif %} Ref prefixes such as `refs/heads` and `refs/tags` are not allowed.
|
||||
`{ref}` can be a SHA, a release tag, or a branch name. Using the commit SHA is the safest for stability and security. For more information, see "[AUTOTITLE](/actions/security-guides/security-hardening-for-github-actions#reusing-third-party-workflows)." If you use the second syntax option (without `{owner}/{repo}` and `@{ref}`) the called workflow is from the same commit as the caller workflow. Ref prefixes such as `refs/heads` and `refs/tags` are not allowed.
|
||||
|
||||
@@ -1,9 +0,0 @@
|
||||
{% ifversion ghes = 3.4 %}
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note**: Reusable workflows are currently in beta and subject to change.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% endif %}
|
||||
@@ -1,2 +1,2 @@
|
||||
{% comment %}This reusable is only to be used in other repo/org/enterprise setting reusables.{%- endcomment -%}
|
||||
1. In the left sidebar, click {% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}{% octicon "play" aria-hidden="true" %} **Actions**, then click **General**.{% else %}**Actions**.{% endif %}
|
||||
1. In the left sidebar, click {% octicon "play" aria-hidden="true" %} **Actions**, then click **General**.
|
||||
|
||||
@@ -1,3 +1,2 @@
|
||||
{% comment %}This reusable is only to be used in other repo/org/enterprise setting reusables.{%- endcomment -%}
|
||||
1. In the left sidebar, click {% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}{% octicon "play" aria-hidden="true" %} **Actions**, then click **Runners**.{% else %}**Actions**.{% ifversion ghes or ghae %}
|
||||
1. In the left sidebar, under "Actions", click **Runners**.{% endif %}{% endif %}
|
||||
1. In the left sidebar, click {% octicon "play" aria-hidden="true" %} **Actions**, then click **Runners**.
|
||||
|
||||
@@ -1,5 +1 @@
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 -%}
|
||||
1. In the "Security" section of the sidebar, select {% ifversion actions-configuration-variables %}**{% octicon "key-asterisk" aria-hidden="true" %} Secrets and variables**, {% else %}**{% octicon "key-asterisk" aaria-hidden="true" %} Secrets**, {% endif %}then click **Actions**.
|
||||
{%- else %}
|
||||
1. In the left sidebar, click **Secrets**.
|
||||
{%- endif %}
|
||||
|
||||
@@ -2,10 +2,8 @@
|
||||
jobs:
|
||||
call-workflow-1-in-local-repo:
|
||||
uses: octo-org/this-repo/.github/workflows/workflow-1.yml@172239021f7ba04fe7327647b213799853a9eb89
|
||||
{%- ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
call-workflow-2-in-local-repo:
|
||||
uses: ./.github/workflows/workflow-2.yml
|
||||
{%- endif %}
|
||||
call-workflow-in-another-repo:
|
||||
uses: octo-org/another-repo/.github/workflows/workflow.yml@v1
|
||||
```
|
||||
|
||||
@@ -4,6 +4,4 @@
|
||||
1. You can click **More options {% octicon "chevron-down" aria-label="down" %}** to provide other surrounding content or additional match requirements for the secret format.
|
||||
1. Provide a sample test string to make sure your configuration is matching the patterns you expect.
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||

|
||||
{% endif %}
|
||||
|
||||
@@ -1 +1 @@
|
||||
1. When you're satisfied with your new custom pattern, click {% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}**Publish pattern**{% else %}**Create pattern**{% endif %}.
|
||||
1. When you're satisfied with your new custom pattern, click **Publish pattern**.
|
||||
|
||||
@@ -1,5 +1 @@
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
1. In the "Archives" section of the sidebar, click {% octicon "log" aria-hidden="true" %} **Logs**, then click **Audit log**.
|
||||
{% else %}
|
||||
1. In the Settings sidebar, click **Audit log**.
|
||||
{% endif %}
|
||||
|
||||
@@ -1,5 +1 @@
|
||||
{% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
1. In the "Archives" section of the sidebar, click **{% octicon "log" aria-hidden="true" %} Security log**.
|
||||
{% else %}
|
||||
1. In the left sidebar, click **Audit log**.
|
||||
{% endif %}
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user