GitHub Enterprise Server 3.5 release candidate (#26792)
После Ширина: | Высота: | Размер: 23 KiB |
После Ширина: | Высота: | Размер: 77 KiB |
После Ширина: | Высота: | Размер: 26 KiB |
После Ширина: | Высота: | Размер: 28 KiB |
До Ширина: | Высота: | Размер: 84 KiB После Ширина: | Высота: | Размер: 852 KiB |
Двоичные данные
assets/images/help/enterprises/enterprise-admin-account-settings-button.png
Normal file
После Ширина: | Высота: | Размер: 15 KiB |
После Ширина: | Высота: | Размер: 7.9 KiB |
После Ширина: | Высота: | Размер: 22 KiB |
После Ширина: | Высота: | Размер: 2.8 KiB |
Двоичные данные
assets/images/help/enterprises/github-enterprise-cloud-organizations.png
Normal file
После Ширина: | Высота: | Размер: 7.2 KiB |
После Ширина: | Высота: | Размер: 43 KiB |
После Ширина: | Высота: | Размер: 7.8 KiB |
Двоичные данные
assets/images/help/server-statistics/enterprise-account-settings-tab.png
Normal file
После Ширина: | Высота: | Размер: 19 KiB |
После Ширина: | Высота: | Размер: 35 KiB |
После Ширина: | Высота: | Размер: 54 KiB |
Двоичные данные
assets/images/help/server-statistics/server-statistics-enable-disable-options.png
Normal file
После Ширина: | Высота: | Размер: 36 KiB |
После Ширина: | Высота: | Размер: 8.6 KiB |
|
@ -50,7 +50,7 @@ You can also view whether an enterprise owner has a specific role in the organiz
|
|||
| Enterprise owner | Organization owner | Able to configure organization settings and manage access to the organization's resources through teams, etc. |
|
||||
| Enterprise owner | Organization member | Able to access organization resources and content, such as repositories, without access to the organization's settings. |
|
||||
|
||||
To review all roles in an organization, see "[Roles in an organization](/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization)." {% ifversion ghec %} An organization member can also have a custom role for a specific repository. For more information, see "[Managing custom repository roles for an organization](/organizations/managing-peoples-access-to-your-organization-with-roles/managing-custom-repository-roles-for-an-organization)."{% endif %}
|
||||
To review all roles in an organization, see "[Roles in an organization](/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization)." {% if custom-repository-roles %} An organization member can also have a custom role for a specific repository. For more information, see "[Managing custom repository roles for an organization](/organizations/managing-peoples-access-to-your-organization-with-roles/managing-custom-repository-roles-for-an-organization)."{% endif %}
|
||||
|
||||
For more information about the enterprise owner role, see "[Roles in an enterprise](/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise#enterprise-owner)."
|
||||
|
||||
|
|
|
@ -22,7 +22,7 @@ shortTitle: Build & test Java & Gradle
|
|||
|
||||
## Introduction
|
||||
|
||||
This guide shows you how to create a workflow that performs continuous integration (CI) for your Java project using the Gradle build system. The workflow you create will allow you to see when commits to a pull request cause build or test failures against your default branch; this approach can help ensure that your code is always healthy. You can extend your CI workflow to cache files and upload artifacts from a workflow run.
|
||||
This guide shows you how to create a workflow that performs continuous integration (CI) for your Java project using the Gradle build system. The workflow you create will allow you to see when commits to a pull request cause build or test failures against your default branch; this approach can help ensure that your code is always healthy. You can extend your CI workflow to {% if actions-caching %}cache files and{% endif %} upload artifacts from a workflow run.
|
||||
|
||||
{% ifversion ghae %}
|
||||
{% data reusables.actions.self-hosted-runners-software %}
|
||||
|
@ -110,12 +110,16 @@ steps:
|
|||
arguments: -b ci.gradle package
|
||||
```
|
||||
|
||||
{% if actions-caching %}
|
||||
|
||||
## Caching dependencies
|
||||
|
||||
When using {% data variables.product.prodname_dotcom %}-hosted runners, your build dependencies can be cached to speed up your workflow runs. After a successful run, the `gradle/gradle-build-action` caches important parts of the Gradle user home directory. In future jobs, the cache will be restored so that build scripts won't need to be recompiled and dependencies won't need to be downloaded from remote package repositories.
|
||||
Your build dependencies can be cached to speed up your workflow runs. After a successful run, the `gradle/gradle-build-action` caches important parts of the Gradle user home directory. In future jobs, the cache will be restored so that build scripts won't need to be recompiled and dependencies won't need to be downloaded from remote package repositories.
|
||||
|
||||
Caching is enabled by default when using the `gradle/gradle-build-action` action. For more information, see [`gradle/gradle-build-action`](https://github.com/gradle/gradle-build-action#caching).
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Packaging workflow data as artifacts
|
||||
|
||||
After your build has succeeded and your tests have passed, you may want to upload the resulting Java packages as a build artifact. This will store the built packages as part of the workflow run, and allow you to download them. Artifacts can help you test and debug pull requests in your local environment before they're merged. For more information, see "[Persisting workflow data using artifacts](/actions/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)."
|
||||
|
|
|
@ -22,7 +22,7 @@ shortTitle: Build & test Java with Maven
|
|||
|
||||
## Introduction
|
||||
|
||||
This guide shows you how to create a workflow that performs continuous integration (CI) for your Java project using the Maven software project management tool. The workflow you create will allow you to see when commits to a pull request cause build or test failures against your default branch; this approach can help ensure that your code is always healthy. You can extend your CI workflow to cache files and upload artifacts from a workflow run.
|
||||
This guide shows you how to create a workflow that performs continuous integration (CI) for your Java project using the Maven software project management tool. The workflow you create will allow you to see when commits to a pull request cause build or test failures against your default branch; this approach can help ensure that your code is always healthy. You can extend your CI workflow to {% if actions-caching %}cache files and{% endif %} upload artifacts from a workflow run.
|
||||
|
||||
{% ifversion ghae %}
|
||||
{% data reusables.actions.self-hosted-runners-software %}
|
||||
|
@ -99,9 +99,11 @@ steps:
|
|||
run: mvn --batch-mode --update-snapshots verify
|
||||
```
|
||||
|
||||
{% if actions-caching %}
|
||||
|
||||
## Caching dependencies
|
||||
|
||||
When using {% data variables.product.prodname_dotcom %}-hosted runners, you can cache your dependencies to speed up your workflow runs. After a successful run, your local Maven repository will be stored on GitHub Actions infrastructure. In future workflow runs, the cache will be restored so that dependencies don't need to be downloaded from remote Maven repositories. You can cache dependencies simply using the [`setup-java` action](https://github.com/marketplace/actions/setup-java-jdk) or can use [`cache` action](https://github.com/actions/cache) for custom and more advanced configuration.
|
||||
You can cache your dependencies to speed up your workflow runs. After a successful run, your local Maven repository will be stored in a cache. In future workflow runs, the cache will be restored so that dependencies don't need to be downloaded from remote Maven repositories. You can cache dependencies simply using the [`setup-java` action](https://github.com/marketplace/actions/setup-java-jdk) or can use [`cache` action](https://github.com/actions/cache) for custom and more advanced configuration.
|
||||
|
||||
```yaml{:copy}
|
||||
steps:
|
||||
|
@ -118,6 +120,8 @@ steps:
|
|||
|
||||
This workflow will save the contents of your local Maven repository, located in the `.m2` directory of the runner's home directory. The cache key will be the hashed contents of _pom.xml_, so changes to _pom.xml_ will invalidate the cache.
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Packaging workflow data as artifacts
|
||||
|
||||
After your build has succeeded and your tests have passed, you may want to upload the resulting Java packages as a build artifact. This will store the built packages as part of the workflow run, and allow you to download them. Artifacts can help you test and debug pull requests in your local environment before they're merged. For more information, see "[Persisting workflow data using artifacts](/actions/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)."
|
||||
|
|
|
@ -120,7 +120,7 @@ steps:
|
|||
run: dotnet add package Newtonsoft.Json --version 12.0.1
|
||||
```
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
{% if actions-caching %}
|
||||
|
||||
### Caching dependencies
|
||||
|
||||
|
|
|
@ -136,7 +136,7 @@ If you don't specify a Node.js version, {% data variables.product.prodname_dotco
|
|||
|
||||
{% data variables.product.prodname_dotcom %}-hosted runners have npm and Yarn dependency managers installed. You can use npm and Yarn to install dependencies in your workflow before building and testing your code. The Windows and Linux {% data variables.product.prodname_dotcom %}-hosted runners also have Grunt, Gulp, and Bower installed.
|
||||
|
||||
When using {% data variables.product.prodname_dotcom %}-hosted runners, you can also cache dependencies to speed up your workflow. For more information, see "<a href="/actions/guides/caching-dependencies-to-speed-up-workflows" class="dotcom-only">Caching dependencies to speed up workflows</a>."
|
||||
{% if actions-caching %}You can also cache dependencies to speed up your workflow. For more information, see "[Caching dependencies to speed up workflows](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)."{% endif %}
|
||||
|
||||
### Example using npm
|
||||
|
||||
|
@ -228,9 +228,11 @@ The example above creates an *.npmrc* file with the following contents:
|
|||
always-auth=true
|
||||
```
|
||||
|
||||
{% if actions-caching %}
|
||||
|
||||
### Example caching dependencies
|
||||
|
||||
When using {% data variables.product.prodname_dotcom %}-hosted runners, you can cache and restore the dependencies using the [`setup-node` action](https://github.com/actions/setup-node).
|
||||
You can cache and restore the dependencies using the [`setup-node` action](https://github.com/actions/setup-node).
|
||||
|
||||
The following example caches dependencies for npm.
|
||||
|
||||
|
@ -278,7 +280,9 @@ steps:
|
|||
- run: pnpm test
|
||||
```
|
||||
|
||||
If you have a custom requirement or need finer controls for caching, you can use the [`cache` action](https://github.com/marketplace/actions/cache). For more information, see "<a href="/actions/guides/caching-dependencies-to-speed-up-workflows" class="dotcom-only">Caching dependencies to speed up workflows</a>".
|
||||
If you have a custom requirement or need finer controls for caching, you can use the [`cache` action](https://github.com/marketplace/actions/cache). For more information, see "[Caching dependencies to speed up workflows](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)."
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Building and testing your code
|
||||
|
||||
|
|
|
@ -104,7 +104,7 @@ The table below describes the locations for various PowerShell modules in each {
|
|||
|
||||
{% endnote %}
|
||||
|
||||
When using {% data variables.product.prodname_dotcom %}-hosted runners, you can also cache dependencies to speed up your workflow. For more information, see "<a href="/actions/guides/caching-dependencies-to-speed-up-workflows" class="dotcom-only">Caching dependencies to speed up workflows</a>."
|
||||
{% if actions-caching %}You can also cache dependencies to speed up your workflow. For more information, see "[Caching dependencies to speed up workflows](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)."{% endif %}
|
||||
|
||||
For example, the following job installs the `SqlServer` and `PSScriptAnalyzer` modules:
|
||||
|
||||
|
@ -128,9 +128,11 @@ jobs:
|
|||
|
||||
{% endnote %}
|
||||
|
||||
{% if actions-caching %}
|
||||
|
||||
### Caching dependencies
|
||||
|
||||
When using {% data variables.product.prodname_dotcom %}-hosted runners, you can cache PowerShell dependencies using a unique key, which allows you to restore the dependencies for future workflows with the [`cache`](https://github.com/marketplace/actions/cache) action. For more information, see "<a href="/actions/guides/caching-dependencies-to-speed-up-workflows" class="dotcom-only">Caching dependencies to speed up workflows</a>."
|
||||
You can cache PowerShell dependencies using a unique key, which allows you to restore the dependencies for future workflows with the [`cache`](https://github.com/marketplace/actions/cache) action. For more information, see "[Caching dependencies to speed up workflows](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)."
|
||||
|
||||
PowerShell caches its dependencies in different locations, depending on the runner's operating system. For example, the `path` location used in the following Ubuntu example will be different for a Windows operating system.
|
||||
|
||||
|
@ -151,6 +153,8 @@ steps:
|
|||
Install-Module SqlServer, PSScriptAnalyzer -ErrorAction Stop
|
||||
```
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Testing your code
|
||||
|
||||
You can use the same commands that you use locally to build and test your code.
|
||||
|
|
|
@ -197,7 +197,7 @@ We recommend using `setup-python` to configure the version of Python used in you
|
|||
|
||||
{% data variables.product.prodname_dotcom %}-hosted runners have the pip package manager installed. You can use pip to install dependencies from the PyPI package registry before building and testing your code. For example, the YAML below installs or upgrades the `pip` package installer and the `setuptools` and `wheel` packages.
|
||||
|
||||
When using {% data variables.product.prodname_dotcom %}-hosted runners, you can also cache dependencies to speed up your workflow. For more information, see "<a href="/actions/guides/caching-dependencies-to-speed-up-workflows" class="dotcom-only">Caching dependencies to speed up workflows</a>."
|
||||
{% if actions-caching %}You can also cache dependencies to speed up your workflow. For more information, see "[Caching dependencies to speed up workflows](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)."{% endif %}
|
||||
|
||||
```yaml{:copy}
|
||||
steps:
|
||||
|
@ -227,9 +227,11 @@ steps:
|
|||
pip install -r requirements.txt
|
||||
```
|
||||
|
||||
{% if actions-caching %}
|
||||
|
||||
### Caching Dependencies
|
||||
|
||||
When using {% data variables.product.prodname_dotcom %}-hosted runners, you can cache and restore the dependencies using the [`setup-python` action](https://github.com/actions/setup-python).
|
||||
You can cache and restore the dependencies using the [`setup-python` action](https://github.com/actions/setup-python).
|
||||
|
||||
The following example caches dependencies for pip.
|
||||
|
||||
|
@ -244,10 +246,12 @@ steps:
|
|||
- run: pip test
|
||||
```
|
||||
|
||||
By default, the `setup-python` action searches for the dependency file (`requirements.txt` for pip or `Pipfile.lock` for pipenv) in the whole repository. For more information, see "<a href="/actions/guides/caching-dependencies-to-speed-up-workflows" class="dotcom-only">Caching packages dependencies</a>" in the `setup-python` actions README.
|
||||
By default, the `setup-python` action searches for the dependency file (`requirements.txt` for pip or `Pipfile.lock` for pipenv) in the whole repository. For more information, see "[Caching packages dependencies](https://github.com/actions/setup-python#caching-packages-dependencies)" in the `setup-python` README.
|
||||
|
||||
If you have a custom requirement or need finer controls for caching, you can use the [`cache` action](https://github.com/marketplace/actions/cache). Pip caches dependencies in different locations, depending on the operating system of the runner. The path you'll need to cache may differ from the Ubuntu example above, depending on the operating system you use. For more information, see [Python caching examples](https://github.com/actions/cache/blob/main/examples.md#python---pip) in the `cache` action repository.
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Testing your code
|
||||
|
||||
You can use the same commands that you use locally to build and test your code.
|
||||
|
|
|
@ -144,9 +144,11 @@ steps:
|
|||
- run: bundle install
|
||||
```
|
||||
|
||||
{% if actions-caching %}
|
||||
|
||||
### Caching dependencies
|
||||
|
||||
If you are using {% data variables.product.prodname_dotcom %}-hosted runners, the `setup-ruby` actions provides a method to automatically handle the caching of your gems between runs.
|
||||
The `setup-ruby` actions provides a method to automatically handle the caching of your gems between runs.
|
||||
|
||||
To enable caching, set the following.
|
||||
|
||||
|
@ -159,11 +161,11 @@ steps:
|
|||
```
|
||||
{% endraw %}
|
||||
|
||||
This will configure bundler to install your gems to `vendor/cache`. For each successful run of your workflow, this folder will be cached by Actions and re-downloaded for subsequent workflow runs. A hash of your gemfile.lock and the Ruby version are used as the cache key. If you install any new gems, or change a version, the cache will be invalidated and bundler will do a fresh install.
|
||||
This will configure bundler to install your gems to `vendor/cache`. For each successful run of your workflow, this folder will be cached by {% data variables.product.prodname_actions %} and re-downloaded for subsequent workflow runs. A hash of your gemfile.lock and the Ruby version are used as the cache key. If you install any new gems, or change a version, the cache will be invalidated and bundler will do a fresh install.
|
||||
|
||||
**Caching without setup-ruby**
|
||||
|
||||
For greater control over caching, if you are using {% data variables.product.prodname_dotcom %}-hosted runners, you can use the `actions/cache` Action directly. For more information, see "<a href="/actions/guides/caching-dependencies-to-speed-up-workflows" class="dotcom-only">Caching dependencies to speed up workflows</a>."
|
||||
For greater control over caching, you can use the `actions/cache` action directly. For more information, see "[Caching dependencies to speed up workflows](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)."
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
|
@ -195,6 +197,8 @@ steps:
|
|||
bundle install --jobs 4 --retry 3
|
||||
```
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Matrix testing your code
|
||||
|
||||
The following example matrix tests all stable releases and head versions of MRI, JRuby and TruffleRuby on Ubuntu and macOS.
|
||||
|
|
|
@ -31,7 +31,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. {% ifversion fpt or ghae or ghes > 3.1 or ghec %}You can use concurrency to limit your CD pipeline to a maximum of one in-progress deployment and one pending deployment. {% endif %}For more information about these features, see "[Deploying with GitHub Actions](/actions/deployment/deploying-with-github-actions)" and "[Using environments for deployment](/actions/deployment/using-environments-for-deployment)."
|
||||
|
||||
{% ifversion fpt or ghec or ghae-issue-4856 %}
|
||||
{% ifversion fpt or ghec or ghae-issue-4856 or ghes > 3.4 %}
|
||||
|
||||
## Using OpenID Connect to access cloud resources
|
||||
|
||||
|
|
|
@ -26,7 +26,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 ghae-issue-4856 %}
|
||||
{% ifversion fpt or ghec or ghae-issue-4856 or ghes > 3.4 %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
|
|
@ -21,7 +21,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 ghae-issue-4856 %}
|
||||
{% ifversion fpt or ghec or ghae-issue-4856 or ghes > 3.4 %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
|
|
@ -20,7 +20,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 ghae-issue-4856 %}
|
||||
{% ifversion fpt or ghec or ghae-issue-4856 or ghes > 3.4 %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
|
|
@ -19,7 +19,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 ghae-issue-4856 %}
|
||||
{% ifversion fpt or ghec or ghae-issue-4856 or ghes > 3.4 %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
|
|
@ -25,7 +25,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 ghae-issue-4856 %}
|
||||
{% ifversion fpt or ghec or ghae-issue-4856 or ghes > 3.4 %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
|
|
@ -19,7 +19,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 ghae-issue-4856 %}
|
||||
{% ifversion fpt or ghec or ghae-issue-4856 or ghes > 3.4 %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
|
|
@ -20,7 +20,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 ghae-issue-4856 %}
|
||||
{% ifversion fpt or ghec or ghae-issue-4856 or ghes > 3.4 %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
|
|
@ -20,7 +20,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 ghae-issue-4856 %}
|
||||
{% ifversion fpt or ghec or ghae-issue-4856 or ghes > 3.4 %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
|
|
@ -20,7 +20,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 ghae-issue-4856 %}
|
||||
{% ifversion fpt or ghec or ghae-issue-4856 or ghes > 3.4 %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
|
|
@ -26,7 +26,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 ghae-issue-4856 %}
|
||||
{% ifversion fpt or ghec or ghae-issue-4856 or ghes > 3.4 %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
|
|
@ -7,6 +7,7 @@ versions:
|
|||
fpt: '*'
|
||||
ghae: issue-4856
|
||||
ghec: '*'
|
||||
ghes: '>=3.5'
|
||||
type: tutorial
|
||||
topics:
|
||||
- Security
|
||||
|
@ -66,11 +67,14 @@ The following example OIDC token uses a subject (`sub`) that references a job en
|
|||
"jti": "example-id",
|
||||
"sub": "repo:octo-org/octo-repo:environment:prod",
|
||||
"environment": "prod",
|
||||
"aud": "https://github.com/octo-org",
|
||||
"aud": "{% ifversion ghes %}https://HOSTNAME{% else %}https://github.com{% endif %}/octo-org",
|
||||
"ref": "refs/heads/main",
|
||||
"sha": "example-sha",
|
||||
"repository": "octo-org/octo-repo",
|
||||
"repository_owner": "octo-org",
|
||||
"actor_id": "12",
|
||||
"repository_id": "74",
|
||||
"repository_owner_id": "65",
|
||||
"run_id": "example-run-id",
|
||||
"run_number": "10",
|
||||
"run_attempt": "2",
|
||||
|
@ -81,21 +85,22 @@ The following example OIDC token uses a subject (`sub`) that references a job en
|
|||
"event_name": "workflow_dispatch",
|
||||
"ref_type": "branch",
|
||||
"job_workflow_ref": "octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main",
|
||||
"iss": "https://token.actions.githubusercontent.com",
|
||||
"iss": "{% ifversion ghes %}https://HOSTNAME/_services/token{% else %}https://token.actions.githubusercontent.com{% endif %}",
|
||||
"nbf": 1632492967,
|
||||
"exp": 1632493867,
|
||||
"iat": 1632493567
|
||||
}
|
||||
```
|
||||
|
||||
To see all the claims supported by {% data variables.product.prodname_dotcom %}'s OIDC provider, review the `claims_supported` entries at https://token.actions.githubusercontent.com/.well-known/openid-configuration.
|
||||
To see all the claims supported by {% data variables.product.prodname_dotcom %}'s OIDC provider, review the `claims_supported` entries at
|
||||
{% ifversion ghes %}`https://HOSTNAME/_services/token/.well-known/openid-configuration`{% else %}https://token.actions.githubusercontent.com/.well-known/openid-configuration{% endif %}.
|
||||
|
||||
The token includes the standard audience, issuer, and subject claims:
|
||||
|
||||
| Claim | Description |
|
||||
| ----------- | ---------------------- |
|
||||
| `aud`| _(Audience)_ By default, this is the URL of the repository owner, such as the organization that owns the repository. This is the only claim that can be customized. You can set a custom audience with a toolkit command: [`core.getIDToken(audience)`](https://www.npmjs.com/package/@actions/core/v/1.6.0) |
|
||||
| `iss`| _(Issuer)_ The issuer of the OIDC token: `https://token.actions.githubusercontent.com` |
|
||||
| `iss`| _(Issuer)_ The issuer of the OIDC token: {% ifversion ghes %}`https://HOSTNAME/_services/token`{% else %}`https://token.actions.githubusercontent.com`{% endif %} |
|
||||
| `sub`| _(Subject)_ Defines the subject claim that is to be validated by the cloud provider. This setting is essential for making sure that access tokens are only allocated in a predictable way.|
|
||||
|
||||
The OIDC token also includes additional standard claims:
|
||||
|
@ -115,6 +120,7 @@ The token also includes custom claims provided by {% data variables.product.prod
|
|||
| Claim | Description |
|
||||
| ----------- | ---------------------- |
|
||||
| `actor`| The personal account that initiated the workflow run. |
|
||||
| `actor_id`| The ID of personal account that initiated the workflow run. |
|
||||
| `base_ref`| The target branch of the pull request in a workflow run. |
|
||||
| `environment`| The name of the environment used by the job. |
|
||||
| `event_name`| The name of the event that triggered the workflow run. |
|
||||
|
@ -123,7 +129,9 @@ The token also includes custom claims provided by {% data variables.product.prod
|
|||
| `ref`| _(Reference)_ The git ref that triggered the workflow run. |
|
||||
| `ref_type`| The type of `ref`, for example: "branch". |
|
||||
| `repository`| The repository from where the workflow is running. |
|
||||
| `repository_id`| The ID of the repository from where the workflow is running. |
|
||||
| `repository_owner`| The name of the organization in which the `repository` is stored. |
|
||||
| `repository_owner_id`| The ID of the organization in which the `repository` is stored. |
|
||||
| `run_id`| The ID of the workflow run that triggered the workflow. |
|
||||
| `run_number`| The number of times this workflow has been run. |
|
||||
| `run_attempt`| The number of times this workflow run has been retried. |
|
||||
|
@ -201,7 +209,7 @@ To configure the subject in your cloud provider's trust relationship, you must a
|
|||
|
||||
| | |
|
||||
| ------ | ----------- |
|
||||
| Amazon Web Services | `"token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:ref:refs/heads/demo-branch"` |
|
||||
| Amazon Web Services | `"{% ifversion ghes %}HOSTNAME/_services/token{% else %}token.actions.githubusercontent.com{% endif %}:sub": "repo:octo-org/octo-repo:ref:refs/heads/demo-branch"` |
|
||||
| Azure| `repo:octo-org/octo-repo:ref:refs/heads/demo-branch` |
|
||||
| Google Cloud Platform| `(assertion.sub=='repo:octo-org/octo-repo:ref:refs/heads/demo-branch')` |
|
||||
| HashiCorp Vault| `bound_subject="repo:octo-org/octo-repo:ref:refs/heads/demo-branch" ` |
|
||||
|
|
|
@ -7,6 +7,7 @@ versions:
|
|||
fpt: '*'
|
||||
ghae: issue-4856
|
||||
ghec: '*'
|
||||
ghes: '>=3.5'
|
||||
type: tutorial
|
||||
topics:
|
||||
- Security
|
||||
|
@ -31,7 +32,7 @@ This guide explains how to configure AWS to trust {% data variables.product.prod
|
|||
|
||||
To add the {% data variables.product.prodname_dotcom %} OIDC provider to IAM, see the [AWS documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html).
|
||||
|
||||
- For the provider URL: Use `https://token.actions.githubusercontent.com`
|
||||
- For the provider URL: Use {% ifversion ghes %}`https://HOSTNAME/_services/token`{% else %}`https://token.actions.githubusercontent.com`{% endif %}
|
||||
- For the "Audience": Use `sts.amazonaws.com` if you are using the [official action](https://github.com/aws-actions/configure-aws-credentials).
|
||||
|
||||
### Configuring the role and trust policy
|
||||
|
@ -42,9 +43,9 @@ Edit the trust relationship to add the `sub` field to the validation conditions.
|
|||
|
||||
```json{:copy}
|
||||
"Condition": {
|
||||
"StringEquals": {
|
||||
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
|
||||
"token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:ref:refs/heads/octo-branch"
|
||||
"ForAllValues:StringEquals": {
|
||||
"{% ifversion ghes %}HOSTNAME/_services/token{% else %}token.actions.githubusercontent.com{% endif %}:aud": "sts.amazonaws.com",
|
||||
"{% ifversion ghes %}HOSTNAME/_services/token{% else %}token.actions.githubusercontent.com{% endif %}:sub": "repo:octo-org/octo-repo:ref:refs/heads/octo-branch"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
|
|
@ -7,6 +7,7 @@ versions:
|
|||
fpt: '*'
|
||||
ghae: issue-4856
|
||||
ghec: '*'
|
||||
ghes: '>=3.5'
|
||||
type: tutorial
|
||||
topics:
|
||||
- Security
|
||||
|
|
|
@ -7,6 +7,7 @@ versions:
|
|||
fpt: '*'
|
||||
ghae: issue-4856
|
||||
ghec: '*'
|
||||
ghes: '>=3.5'
|
||||
type: tutorial
|
||||
topics:
|
||||
- Security
|
||||
|
|
|
@ -7,6 +7,7 @@ versions:
|
|||
fpt: '*'
|
||||
ghae: issue-4856
|
||||
ghec: '*'
|
||||
ghes: '>=3.5'
|
||||
type: tutorial
|
||||
topics:
|
||||
- Security
|
||||
|
@ -39,7 +40,7 @@ Additional guidance for configuring the identity provider:
|
|||
|
||||
- For security hardening, make sure you've reviewed ["Configuring the OIDC trust with the cloud"](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-oidc-trust-with-the-cloud). For an example, see ["Configuring the subject in your cloud provider"](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-subject-in-your-cloud-provider).
|
||||
- For the service account to be available for configuration, it needs to be assigned to the `roles/iam.workloadIdentityUser` role. For more information, see [the GCP documentation](https://cloud.google.com/iam/docs/workload-identity-federation?_ga=2.114275588.-285296507.1634918453#conditions).
|
||||
- The Issuer URL to use: `https://token.actions.githubusercontent.com`
|
||||
- The Issuer URL to use: {% ifversion ghes %}`https://HOSTNAME/_services/token`{% else %}`https://token.actions.githubusercontent.com`{% endif %}
|
||||
|
||||
## Updating your {% data variables.product.prodname_actions %} workflow
|
||||
|
||||
|
|
|
@ -7,6 +7,7 @@ versions:
|
|||
fpt: '*'
|
||||
ghae: issue-4856
|
||||
ghec: '*'
|
||||
ghes: '>=3.5'
|
||||
type: tutorial
|
||||
topics:
|
||||
- Security
|
||||
|
@ -32,8 +33,8 @@ This guide gives an overview of how to configure HashiCorp Vault to trust {% dat
|
|||
To use OIDC with HashiCorp Vault, you will need to add a trust configuration for the {% data variables.product.prodname_dotcom %} OIDC provider. For more information, see the HashiCorp Vault [documentation](https://www.vaultproject.io/docs/auth/jwt).
|
||||
|
||||
Configure the vault to accept JSON Web Tokens (JWT) for authentication:
|
||||
- For the `oidc_discovery_url`, use `https://token.actions.githubusercontent.com`
|
||||
- For `bound_issuer`, use `https://token.actions.githubusercontent.com`
|
||||
- For the `oidc_discovery_url`, use {% ifversion ghes %}`https://HOSTNAME/_services/token`{% else %}`https://token.actions.githubusercontent.com`{% endif %}
|
||||
- For `bound_issuer`, use {% ifversion ghes %}`https://HOSTNAME/_services/token`{% else %}`https://token.actions.githubusercontent.com`{% endif %}
|
||||
- Ensure that `bound_subject` is correctly defined for your security requirements. For more information, see ["Configuring the OIDC trust with the cloud"](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-oidc-trust-with-the-cloud) and [`hashicorp/vault-action`](https://github.com/hashicorp/vault-action).
|
||||
|
||||
## Updating your {% data variables.product.prodname_actions %} workflow
|
||||
|
|
|
@ -6,6 +6,7 @@ versions:
|
|||
fpt: '*'
|
||||
ghae: issue-4856
|
||||
ghec: '*'
|
||||
ghes: '>=3.5'
|
||||
children:
|
||||
- /about-security-hardening-with-openid-connect
|
||||
- /configuring-openid-connect-in-amazon-web-services
|
||||
|
|
|
@ -45,11 +45,14 @@ For example, the following OIDC token is for a job that was part of a called wor
|
|||
{
|
||||
"jti": "example-id",
|
||||
"sub": "repo:octo-org/octo-repo:environment:prod",
|
||||
"aud": "https://github.com/octo-org",
|
||||
"aud": "{% ifversion ghes %}https://HOSTNAME{% else %}https://github.com{% endif %}/octo-org",
|
||||
"ref": "refs/heads/main",
|
||||
"sha": "example-sha",
|
||||
"repository": "octo-org/octo-repo",
|
||||
"repository_owner": "octo-org",
|
||||
"actor_id": "12",
|
||||
"repository_id": "74",
|
||||
"repository_owner_id": "65",
|
||||
"run_id": "example-run-id",
|
||||
"run_number": "10",
|
||||
"run_attempt": "2",
|
||||
|
@ -60,7 +63,7 @@ For example, the following OIDC token is for a job that was part of a called wor
|
|||
"event_name": "workflow_dispatch",
|
||||
"ref_type": "branch",
|
||||
"job_workflow_ref": "octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main",
|
||||
"iss": "https://token.actions.githubusercontent.com",
|
||||
"iss": "{% ifversion ghes %}https://HOSTNAME/_services/token{% else %}https://token.actions.githubusercontent.com{% endif %}",
|
||||
"nbf": 1632492967,
|
||||
"exp": 1632493867,
|
||||
"iat": 1632493567
|
||||
|
|
|
@ -81,6 +81,8 @@ For more information, see "[Using environment variables](/actions/configuring-an
|
|||
|
||||
CircleCI and {% data variables.product.prodname_actions %} provide a method to manually cache files in the configuration file.
|
||||
|
||||
{% if actions-caching %}
|
||||
|
||||
Below is an example of the syntax for each system.
|
||||
|
||||
<table class="d-block">
|
||||
|
@ -118,7 +120,11 @@ GitHub Actions
|
|||
</tr>
|
||||
</table>
|
||||
|
||||
{% data variables.product.prodname_actions %} caching is only applicable for repositories hosted on {% data variables.product.prodname_dotcom_the_website %}. For more information, see "<a href="/actions/guides/caching-dependencies-to-speed-up-workflows" class="dotcom-only">Caching dependencies to speed up workflows</a>."
|
||||
{% else %}
|
||||
|
||||
{% data reusables.actions.caching-availability %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% data variables.product.prodname_actions %} does not have an equivalent of CircleCI’s Docker Layer Caching (or DLC).
|
||||
|
||||
|
|
|
@ -309,6 +309,8 @@ For more information, see "[Environment variables](/actions/reference/environmen
|
|||
|
||||
GitLab CI/CD and {% data variables.product.prodname_actions %} provide a method in the configuration file to manually cache workflow files.
|
||||
|
||||
{% if actions-caching %}
|
||||
|
||||
Below is an example of the syntax for each system:
|
||||
|
||||
<table class="d-block">
|
||||
|
@ -359,7 +361,11 @@ jobs:
|
|||
</tr>
|
||||
</table>
|
||||
|
||||
{% data variables.product.prodname_actions %} caching is only applicable for repositories hosted on {% data variables.product.prodname_dotcom_the_website %}. For more information, see "<a href="/actions/guides/caching-dependencies-to-speed-up-workflows" class="dotcom-only">Caching dependencies to speed up workflows</a>."
|
||||
{% else %}
|
||||
|
||||
{% data reusables.actions.caching-availability %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Artifacts
|
||||
|
||||
|
|
|
@ -303,7 +303,11 @@ jobs:
|
|||
|
||||
## Caching dependencies
|
||||
|
||||
Travis CI and {% data variables.product.prodname_actions %} let you manually cache dependencies for later reuse. This example demonstrates the cache syntax for each system.
|
||||
Travis CI and {% data variables.product.prodname_actions %} let you manually cache dependencies for later reuse.
|
||||
|
||||
{% if actions-caching %}
|
||||
|
||||
This example demonstrates the cache syntax for each system.
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
|
@ -338,7 +342,11 @@ cache: npm
|
|||
</tr>
|
||||
</table>
|
||||
|
||||
{% data variables.product.prodname_actions %} caching is only applicable for repositories hosted on {% data variables.product.prodname_dotcom_the_website %}. For more information, see "<a href="/actions/guides/caching-dependencies-to-speed-up-workflows" class="dotcom-only">Caching dependencies to speed up workflows</a>."
|
||||
{% else %}
|
||||
|
||||
{% data reusables.actions.caching-availability %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Examples of common tasks
|
||||
|
||||
|
|
|
@ -78,7 +78,7 @@ on:
|
|||
jobs:
|
||||
push_to_registry:
|
||||
name: Push Docker image to Docker Hub
|
||||
runs-on: ubuntu-latest
|
||||
runs-on: {% ifversion ghes %}[self-hosted]{% else %}ubuntu-latest{% endif %}
|
||||
steps:
|
||||
- name: Check out the repo
|
||||
uses: {% data reusables.actions.action-checkout %}
|
||||
|
@ -108,12 +108,16 @@ The above workflow checks out the {% data variables.product.prodname_dotcom %} r
|
|||
|
||||
## Publishing images to {% data variables.product.prodname_registry %}
|
||||
|
||||
{% ifversion ghes > 3.4 %}
|
||||
{% data reusables.package_registry.container-registry-ghes-beta %}
|
||||
{% endif %}
|
||||
|
||||
{% data reusables.actions.release-trigger-workflow %}
|
||||
|
||||
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`{% else %}`docker.pkg.github.com`{% endif %}.
|
||||
* `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 %}.
|
||||
* `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 "[Contexts](/actions/learn-github-actions/contexts#github-context)."
|
||||
* `password`: You can use the automatically-generated `GITHUB_TOKEN` secret for the password. For more information, see "[Authenticating with the GITHUB_TOKEN](/actions/automating-your-workflow-with-github-actions/authenticating-with-the-github_token)."
|
||||
|
||||
|
@ -126,9 +130,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 `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`. You can set a single tag as shown below, or specify multiple tags in a list.{% endif %}
|
||||
* `tags`: Must be set in the format {% ifversion ghes > 3.4 %}`{% 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 %}
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
{% 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 %}.
|
||||
|
@ -170,11 +178,15 @@ jobs:
|
|||
{% ifversion ghae %}docker.YOUR-HOSTNAME.com{% else %}docker.pkg.github.com{% endif %}{% raw %}/${{ github.repository }}/octo-image:${{ github.event.release.tag_name }}{% endraw %}
|
||||
```
|
||||
|
||||
The above workflow checks out the {% data variables.product.prodname_dotcom %} repository, uses the `login-action` to log in to the registry, and then uses the `build-push-action` action to: build a Docker image based on your repository's `Dockerfile`; push the image to the Docker registry, and apply the commit SHA and release version as image tags.
|
||||
The above workflow checks out the {% data variables.product.product_name %} repository, uses the `login-action` to log in to the registry, and then uses the `build-push-action` action to: build a Docker image based on your repository's `Dockerfile`; push the image to the Docker registry, and apply the commit SHA and release version as image tags.
|
||||
{% endif %}
|
||||
|
||||
## Publishing images to Docker Hub and {% data variables.product.prodname_registry %}
|
||||
|
||||
{% ifversion ghes > 3.4 %}
|
||||
{% data reusables.package_registry.container-registry-ghes-beta %}
|
||||
{% endif %}
|
||||
|
||||
In a single workflow, you can publish your Docker image to multiple registries by using the `login-action` and `build-push-action` actions for each registry.
|
||||
|
||||
The following example workflow uses the steps from the previous sections ("[Publishing images to Docker Hub](#publishing-images-to-docker-hub)" and "[Publishing images to {% data variables.product.prodname_registry %}](#publishing-images-to-github-packages)") to create a single workflow that pushes to both registries.
|
||||
|
@ -191,7 +203,7 @@ on:
|
|||
jobs:
|
||||
push_to_registries:
|
||||
name: Push Docker image to multiple registries
|
||||
runs-on: ubuntu-latest{% ifversion fpt or ghes > 3.1 or ghae or ghec %}
|
||||
runs-on: {% ifversion ghes %}[self-hosted]{% else %}ubuntu-latest{% endif %}{% ifversion fpt or ghes > 3.1 or ghae or ghec %}
|
||||
permissions:
|
||||
packages: write
|
||||
contents: read{% endif %}
|
||||
|
@ -205,10 +217,10 @@ jobs:
|
|||
username: {% raw %}${{ secrets.DOCKER_USERNAME }}{% endraw %}
|
||||
password: {% raw %}${{ secrets.DOCKER_PASSWORD }}{% endraw %}
|
||||
|
||||
- name: Log in to the {% ifversion fpt or ghec %}Container{% else %}Docker{% endif %} registry
|
||||
- name: Log in to the {% ifversion fpt or ghec or ghes > 3.4 %}Container{% else %}Docker{% endif %} registry
|
||||
uses: docker/login-action@f054a8b539a109f9f41c372932f1ae047eff08c9
|
||||
with:
|
||||
registry: {% ifversion fpt or ghec %}ghcr.io{% elsif ghae %}docker.YOUR-HOSTNAME.com{% else %}docker.pkg.github.com{% endif %}
|
||||
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 %}
|
||||
username: {% raw %}${{ github.actor }}{% endraw %}
|
||||
password: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
|
||||
|
||||
|
@ -218,7 +230,7 @@ jobs:
|
|||
with:
|
||||
images: |
|
||||
my-docker-hub-namespace/my-docker-hub-repository
|
||||
{% ifversion fpt or ghec %}ghcr.io/{% 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 > 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 %}
|
||||
|
||||
- name: Build and push Docker images
|
||||
uses: docker/build-push-action@ad44023a93711e3deb337508980b4b5e9bcdc5dc
|
||||
|
@ -229,5 +241,5 @@ jobs:
|
|||
labels: {% raw %}${{ steps.meta.outputs.labels }}{% endraw %}
|
||||
```
|
||||
|
||||
The above workflow checks out the {% data variables.product.prodname_dotcom %} 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 %}{% data variables.product.prodname_container_registry %}{% else %}Docker registry{% endif %}.
|
||||
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 %}.
|
||||
|
|
|
@ -25,7 +25,7 @@ Secrets are encrypted environment variables that you create in an organization,
|
|||
|
||||
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 ghae-issue-4856 %}
|
||||
{% ifversion fpt or ghec or ghae-issue-4856 or ghes > 3.4 %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
|
|
@ -159,7 +159,7 @@ For more information, see "[About {% data variables.product.prodname_code_scanni
|
|||
|
||||
To help mitigate the risk of an exposed token, consider restricting the assigned permissions. For more information, see "[Modifying the permissions for the GITHUB_TOKEN](/actions/reference/authentication-in-a-workflow#modifying-the-permissions-for-the-github_token)."
|
||||
|
||||
{% ifversion fpt or ghec or ghae-issue-4856 %}
|
||||
{% ifversion fpt or ghec or ghae-issue-4856 or ghes > 3.4 %}
|
||||
|
||||
## Using OpenID Connect to access cloud resources
|
||||
|
||||
|
@ -291,7 +291,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 ghae-issue-4856 %}
|
||||
{% ifversion fpt or ghec or ghae-issue-4856 or ghes > 3.4 %}
|
||||
### Authenticating to your cloud provider
|
||||
|
||||
If you are using {% data variables.product.prodname_actions %} to deploy to a cloud provider, or intend to use HashiCorp Vault for secret management, then its recommended that you consider using OpenID Connect to create short-lived, well-scoped access tokens for your workflow runs. For more information, see "[About security hardening with OpenID Connect](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect)."
|
||||
|
|
|
@ -124,10 +124,10 @@ jobs:
|
|||
|
||||
For more information, see "[Using a matrix for your jobs](/actions/using-jobs/using-a-matrix-for-your-jobs)."
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
{% if actions-caching %}
|
||||
### Caching dependencies
|
||||
|
||||
{% data variables.product.prodname_dotcom %}-hosted runners are started as fresh environments for each job, so if your jobs regularly reuse dependencies, you can consider caching these files to help improve performance. Once the cache is created, it is available to all workflows in the same repository.
|
||||
If your jobs regularly reuse dependencies, you can consider caching these files to help improve performance. Once the cache is created, it is available to all workflows in the same repository.
|
||||
|
||||
This example demonstrates how to cache the ` ~/.npm` directory:
|
||||
|
||||
|
|
|
@ -9,22 +9,20 @@ redirect_from:
|
|||
- /actions/guides/caching-dependencies-to-speed-up-workflows
|
||||
- /actions/advanced-guides/caching-dependencies-to-speed-up-workflows
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
feature: 'actions-caching'
|
||||
type: tutorial
|
||||
topics:
|
||||
- Workflows
|
||||
miniTocMaxHeadingLevel: 3
|
||||
---
|
||||
|
||||
## About caching workflow dependencies
|
||||
|
||||
Workflow runs often reuse the same outputs or downloaded dependencies from one run to another. For example, package and dependency management tools such as Maven, Gradle, npm, and Yarn keep a local cache of downloaded dependencies.
|
||||
|
||||
Jobs on {% data variables.product.prodname_dotcom %}-hosted runners start in a clean virtual environment and must download dependencies each time, causing increased network utilization, longer runtime, and increased cost. To help speed up the time it takes to recreate these files, {% data variables.product.prodname_dotcom %} can cache dependencies you frequently use in workflows.
|
||||
{% ifversion fpt or ghec %} Jobs on {% data variables.product.prodname_dotcom %}-hosted runners start in a clean virtual environment and must download dependencies each time, causing increased network utilization, longer runtime, and increased cost. {% endif %}To help speed up the time it takes to recreate files like dependencies, {% data variables.product.prodname_dotcom %} can cache files you frequently use in workflows.
|
||||
|
||||
To cache dependencies for a job, you'll need to use {% data variables.product.prodname_dotcom %}'s `cache` action. The action retrieves a cache identified by a unique key. For more information, see [`actions/cache`](https://github.com/actions/cache).
|
||||
|
||||
If you are caching the package managers listed below, consider using the respective setup-* actions, which require almost zero configuration and are easy to use.
|
||||
To cache dependencies for a job, you can use {% data variables.product.prodname_dotcom %}'s [`cache` action](https://github.com/actions/cache). The action creates and restores a cache identified by a unique key. Alternatively, if you are caching the package managers listed below, using their respective setup-* actions requires minimal configuration and will create and restore dependency caches for you.
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
|
@ -36,62 +34,59 @@ If you are caching the package managers listed below, consider using the respect
|
|||
<tbody>
|
||||
<tr>
|
||||
<td>npm, yarn, pnpm</td>
|
||||
<td><a href="https://github.com/actions/setup-node">setup-node</a></td>
|
||||
<td><a href="https://github.com/actions/setup-node#caching-global-packages-data">setup-node</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>pip, pipenv</td>
|
||||
<td><a href="https://github.com/actions/setup-python">setup-python</a></td>
|
||||
<td><a href="https://github.com/actions/setup-python#caching-packages-dependencies">setup-python</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>gradle, maven</td>
|
||||
<td><a href="https://github.com/actions/setup-java">setup-java</a></td>
|
||||
<td><a href="https://github.com/actions/setup-java#caching-packages-dependencies">setup-java</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>ruby gems</td>
|
||||
<td><a href="https://github.com/ruby/setup-ruby">setup-ruby</a></td>
|
||||
<td><a href="https://github.com/ruby/setup-ruby#caching-bundle-install-automatically">setup-ruby</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
{% warning %}
|
||||
|
||||
**Warning**: We recommend that you don't store any sensitive information in the cache of public repositories. For example, sensitive information can include access tokens or login credentials stored in a file in the cache path. Also, command line interface (CLI) programs like `docker login` can save access credentials in a configuration file. Anyone with read access can create a pull request on a repository and access the contents of the cache. Forks of a repository can also create pull requests on the base branch and access caches on the base branch.
|
||||
**Warning**: {% ifversion fpt or ghec %}Be mindful of the following when using caching with {% data variables.product.prodname_actions %}:
|
||||
|
||||
* {% endif %}We recommend that you don't store any sensitive information in the cache. For example, sensitive information can include access tokens or login credentials stored in a file in the cache path. Also, command line interface (CLI) programs like `docker login` can save access credentials in a configuration file. Anyone with read access can create a pull request on a repository and access the contents of a cache. Forks of a repository can also create pull requests on the base branch and access caches on the base branch.
|
||||
{%- ifversion fpt or ghec %}
|
||||
* When using self-hosted runners, caches from workflow runs are stored on {% data variables.product.company_short %}-owned cloud storage. A customer-owned storage solution is only available with {% data variables.product.prodname_ghe_server %}.
|
||||
{%- endif %}
|
||||
|
||||
{% endwarning %}
|
||||
|
||||
## Comparing artifacts and dependency caching
|
||||
{% data reusables.actions.comparing-artifacts-caching %}
|
||||
|
||||
Artifacts and caching are similar because they provide the ability to store files on {% data variables.product.prodname_dotcom %}, but each feature offers different use cases and cannot be used interchangeably.
|
||||
|
||||
- Use caching when you want to reuse files that don't change often between jobs or workflow runs.
|
||||
- Use artifacts when you want to save files produced by a job to view after a workflow has ended. For more information, see "[Persisting workflow data using artifacts](/github/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)."
|
||||
For more information on workflow run artifacts, see "[Persisting workflow data using artifacts](/github/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)."
|
||||
|
||||
## Restrictions for accessing a cache
|
||||
|
||||
With `v2` of the `cache` action, you can access the cache in workflows triggered by any event that has a `GITHUB_REF`. If you are using `v1` of the `cache` action, you can only access the cache in workflows triggered by `push` and `pull_request` events, except for the `pull_request` `closed` event. For more information, see "[Events that trigger workflows](/actions/reference/events-that-trigger-workflows)."
|
||||
|
||||
A workflow can access and restore a cache created in the current branch, the base branch (including base branches of forked repositories), or the default branch (usually `main`). For example, a cache created on the default branch would be accessible from any pull request. Also, if the branch `feature-b` has the base branch `feature-a`, a workflow triggered on `feature-b` would have access to caches created in the default branch (`main`), `feature-a`, and `feature-b`.
|
||||
|
||||
Access restrictions provide cache isolation and security by creating a logical boundary between different branches. For example, a cache created for the branch `feature-a` (with the base `main`) would not be accessible to a pull request for the branch `feature-b` (with the base `main`).
|
||||
Access restrictions provide cache isolation and security by creating a logical boundary between different branches. For example, a cache created for the branch `feature-a` (with the base `main`) would not be accessible to a pull request for the branch `feature-c` (with the base `main`).
|
||||
|
||||
Multiple workflows within a repository share cache entries. A cache created for a branch within a workflow can be accessed and restored from another workflow for the same repository and branch.
|
||||
|
||||
## Using the `cache` action
|
||||
|
||||
The `cache` action will attempt to restore a cache based on the `key` you provide. When the action finds a cache, the action restores the cached files to the `path` you configure.
|
||||
The [`cache` action](https://github.com/actions/cache) will attempt to restore a cache based on the `key` you provide. When the action finds a cache, the action restores the cached files to the `path` you configure.
|
||||
|
||||
If there is no exact match, the action creates a new cache entry if the job completes successfully. The new cache will use the `key` you provided and contains the files in the `path` directory.
|
||||
If there is no exact match, the action automatically creates a new cache if the job completes successfully. The new cache will use the `key` you provided and contains the files you specify in `path`.
|
||||
|
||||
You can optionally provide a list of `restore-keys` to use when the `key` doesn't match an existing cache. A list of `restore-keys` is useful when you are restoring a cache from another branch because `restore-keys` can partially match cache keys. For more information about matching `restore-keys`, see "[Matching a cache key](#matching-a-cache-key)."
|
||||
|
||||
For more information, see [`actions/cache`](https://github.com/actions/cache).
|
||||
|
||||
### Input parameters for the `cache` action
|
||||
|
||||
- `key`: **Required** The key created when saving a cache and the key used to search for a cache. Can be any combination of variables, context values, static strings, and functions. Keys have a maximum length of 512 characters, and keys longer than the maximum length will cause the action to fail.
|
||||
- `path`: **Required** The file path on the runner to cache or restore. The path can be an absolute path or relative to the workspace directory.
|
||||
- Paths can be either directories or single files, and glob patterns are supported.
|
||||
- With `v2` of the `cache` action, you can specify a single path, or you can add multiple paths on separate lines. For example:
|
||||
- `key`: **Required** The key created when saving a cache and the key used to search for a cache. It can be any combination of variables, context values, static strings, and functions. Keys have a maximum length of 512 characters, and keys longer than the maximum length will cause the action to fail.
|
||||
- `path`: **Required** The path(s) on the runner to cache or restore.
|
||||
- You can specify a single path, or you can add multiple paths on separate lines. For example:
|
||||
|
||||
```
|
||||
- name: Cache Gradle packages
|
||||
|
@ -101,14 +96,15 @@ For more information, see [`actions/cache`](https://github.com/actions/cache).
|
|||
~/.gradle/caches
|
||||
~/.gradle/wrapper
|
||||
```
|
||||
- With `v1` of the `cache` action, only a single path is supported and it must be a directory. You cannot cache a single file.
|
||||
- `restore-keys`: **Optional** A string containing alternative restore keys, with each restore key placed on a new line. If no cache hit occurred for `key`, these restore keys are used sequentially in the order provided to find and restore a cache. For example:
|
||||
- You can specify either directories or single files, and glob patterns are supported.
|
||||
- You can specify absolute paths, or paths relative to the workspace directory.
|
||||
- `restore-keys`: **Optional** A string containing alternative restore keys, with each restore key placed on a new line. If no cache hit occurs for `key`, these restore keys are used sequentially in the order provided to find and restore a cache. For example:
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
restore-keys: |
|
||||
npm-foobar-${{ hashFiles('package-lock.json') }}
|
||||
npm-foobar-
|
||||
npm-feature-${{ hashFiles('package-lock.json') }}
|
||||
npm-feature-
|
||||
npm-
|
||||
```
|
||||
{% endraw %}
|
||||
|
@ -123,17 +119,15 @@ This example creates a new cache when the packages in `package-lock.json` file c
|
|||
|
||||
```yaml{:copy}
|
||||
name: Caching with npm
|
||||
|
||||
on: push
|
||||
|
||||
jobs:
|
||||
build:
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- uses: {% data reusables.actions.action-checkout %}
|
||||
|
||||
- name: Cache node modules
|
||||
id: cache-npm
|
||||
uses: {% data reusables.actions.action-cache %}
|
||||
env:
|
||||
cache-name: cache-node-modules
|
||||
|
@ -146,7 +140,12 @@ jobs:
|
|||
{% raw %}${{ runner.os }}-build-{% endraw %}
|
||||
{% raw %}${{ runner.os }}-{% endraw %}
|
||||
|
||||
- name: Install Dependencies
|
||||
- if: {% raw %}${{ steps.cache-npm.outputs.cache-hit == false }}{% endraw %}
|
||||
name: List the state of node modules
|
||||
continue-on-error: true
|
||||
run: npm list
|
||||
|
||||
- name: Install dependencies
|
||||
run: npm install
|
||||
|
||||
- name: Build
|
||||
|
@ -156,23 +155,27 @@ jobs:
|
|||
run: npm test
|
||||
```
|
||||
|
||||
When `key` matches an existing cache, it's called a cache hit, and the action restores the cached files to the `path` directory.
|
||||
When `key` matches an existing cache, it's called a _cache hit_, and the action restores the cached files to the `path` directory.
|
||||
|
||||
When `key` doesn't match an existing cache, it's called a cache miss, and a new cache is created if the job completes successfully. When a cache miss occurs, the action searches for alternate keys called `restore-keys`.
|
||||
When `key` doesn't match an existing cache, it's called a _cache miss_, and a new cache is automatically created if the job completes successfully.
|
||||
|
||||
When a cache miss occurs, the action also searches your specified `restore-keys` for any matches:
|
||||
|
||||
1. If you provide `restore-keys`, the `cache` action sequentially searches for any caches that match the list of `restore-keys`.
|
||||
- When there is an exact match, the action restores the files in the cache to the `path` directory.
|
||||
- If there are no exact matches, the action searches for partial matches of the restore keys. When the action finds a partial match, the most recent cache is restored to the `path` directory.
|
||||
1. The `cache` action completes and the next workflow step in the job runs.
|
||||
1. If the job completes successfully, the action creates a new cache with the contents of the `path` directory.
|
||||
1. The `cache` action completes and the next step in the job runs.
|
||||
1. If the job completes successfully, the action automatically creates a new cache with the contents of the `path` directory.
|
||||
|
||||
To cache files in more than one directory, you will need a step that uses the [`cache`](https://github.com/actions/cache) action for each directory. Once you create a cache, you cannot change the contents of an existing cache but you can create a new cache with a new key.
|
||||
For a more detailed explanation of the cache matching process, see "[Matching a cache key](#matching-a-cache-key)." Once you create a cache, you cannot change the contents of an existing cache but you can create a new cache with a new key.
|
||||
|
||||
### Using contexts to create cache keys
|
||||
|
||||
A cache key can include any of the contexts, functions, literals, and operators supported by {% data variables.product.prodname_actions %}. For more information, see "[Expressions](/actions/learn-github-actions/expressions)."
|
||||
A cache key can include any of the contexts, functions, literals, and operators supported by {% data variables.product.prodname_actions %}. For more information, see "[Contexts](/actions/learn-github-actions/contexts)" and "[Expressions](/actions/learn-github-actions/expressions)."
|
||||
|
||||
Using expressions to create a `key` allows you to automatically create a new cache when dependencies have changed. For example, you can create a `key` using an expression that calculates the hash of an npm `package-lock.json` file.
|
||||
Using expressions to create a `key` allows you to automatically create a new cache when dependencies change.
|
||||
|
||||
For example, you can create a `key` using an expression that calculates the hash of an npm `package-lock.json` file. So, when the dependencies that make up the `package-lock.json` file change, the cache key changes and a new cache is automatically created.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
|
@ -186,19 +189,32 @@ npm-${{ hashFiles('package-lock.json') }}
|
|||
npm-d5ea0750
|
||||
```
|
||||
|
||||
### Using the output of the `cache` action
|
||||
|
||||
You can use the output of the `cache` action to do something based on whether a cache hit or miss occurred. If there is a cache miss (an exact match for a cache was not found for the specified `key`), the `cache-hit` output is set to `false`.
|
||||
|
||||
In the example workflow above, there is a step that lists the state of the Node modules if a cache miss occurred:
|
||||
|
||||
```yaml
|
||||
- if: {% raw %}${{ steps.cache-npm.outputs.cache-hit == false }}{% endraw %}
|
||||
name: List the state of node modules
|
||||
continue-on-error: true
|
||||
run: npm list
|
||||
```
|
||||
|
||||
## Matching a cache key
|
||||
|
||||
The `cache` action first searches for cache hits for `key` and `restore-keys` in the branch containing the workflow run. If there are no hits in the current branch, the `cache` action searches for `key` and `restore-keys` in the parent branch and upstream branches.
|
||||
|
||||
You can provide a list of restore keys to use when there is a cache miss on `key`. You can create multiple restore keys ordered from the most specific to least specific. The `cache` action searches for `restore-keys` in sequential order. When a key doesn't match directly, the action searches for keys prefixed with the restore key. If there are multiple partial matches for a restore key, the action returns the most recently created cache.
|
||||
`restore-keys` allows you to specify a list of alternate restore keys to use when there is a cache miss on `key`. You can create multiple restore keys ordered from the most specific to least specific. The `cache` action searches the `restore-keys` in sequential order. When a key doesn't match directly, the action searches for keys prefixed with the restore key. If there are multiple partial matches for a restore key, the action returns the most recently created cache.
|
||||
|
||||
### Example using multiple restore keys
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
restore-keys: |
|
||||
npm-foobar-${{ hashFiles('package-lock.json') }}
|
||||
npm-foobar-
|
||||
npm-feature-${{ hashFiles('package-lock.json') }}
|
||||
npm-feature-
|
||||
npm-
|
||||
```
|
||||
{% endraw %}
|
||||
|
@ -208,16 +224,16 @@ The runner evaluates the expressions, which resolve to these `restore-keys`:
|
|||
{% raw %}
|
||||
```yaml
|
||||
restore-keys: |
|
||||
npm-foobar-d5ea0750
|
||||
npm-foobar-
|
||||
npm-feature-d5ea0750
|
||||
npm-feature-
|
||||
npm-
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
The restore key `npm-foobar-` matches any key that starts with the string `npm-foobar-`. For example, both of the keys `npm-foobar-fd3052de` and `npm-foobar-a9b253ff` match the restore key. The cache with the most recent creation date would be used. The keys in this example are searched in the following order:
|
||||
The restore key `npm-feature-` matches any key that starts with the string `npm-feature-`. For example, both of the keys `npm-feature-fd3052de` and `npm-feature-a9b253ff` match the restore key. The cache with the most recent creation date would be used. The keys in this example are searched in the following order:
|
||||
|
||||
1. **`npm-foobar-d5ea0750`** matches a specific hash.
|
||||
1. **`npm-foobar-`** matches cache keys prefixed with `npm-foobar-`.
|
||||
1. **`npm-feature-d5ea0750`** matches a specific hash.
|
||||
1. **`npm-feature-`** matches cache keys prefixed with `npm-feature-`.
|
||||
1. **`npm-`** matches any keys prefixed with `npm-`.
|
||||
|
||||
#### Example of search priority
|
||||
|
@ -230,18 +246,24 @@ restore-keys: |
|
|||
npm-
|
||||
```
|
||||
|
||||
For example, if a pull request contains a `feature` branch (the current scope) and targets the default branch (`main`), the action searches for `key` and `restore-keys` in the following order:
|
||||
For example, if a pull request contains a `feature` branch and targets the default branch (`main`), the action searches for `key` and `restore-keys` in the following order:
|
||||
|
||||
1. Key `npm-feature-d5ea0750` in the `feature` branch scope
|
||||
1. Key `npm-feature-` in the `feature` branch scope
|
||||
2. Key `npm-` in the `feature` branch scope
|
||||
1. Key `npm-feature-d5ea0750` in the `main` branch scope
|
||||
3. Key `npm-feature-` in the `main` branch scope
|
||||
4. Key `npm-` in the `main` branch scope
|
||||
1. Key `npm-feature-d5ea0750` in the `feature` branch
|
||||
1. Key `npm-feature-` in the `feature` branch
|
||||
1. Key `npm-` in the `feature` branch
|
||||
1. Key `npm-feature-d5ea0750` in the `main` branch
|
||||
1. Key `npm-feature-` in the `main` branch
|
||||
1. Key `npm-` in the `main` branch
|
||||
|
||||
## Usage limits and eviction policy
|
||||
|
||||
{% data variables.product.prodname_dotcom %} will remove any cache entries that have not been accessed in over 7 days. There is no limit on the number of caches you can store, but the total size of all caches in a repository is limited to 10 GB. If you exceed this limit, {% data variables.product.prodname_dotcom %} will save your cache but will begin evicting caches until the total size is less than 10 GB.
|
||||
{% data variables.product.prodname_dotcom %} will remove any cache entries that have not been accessed in over 7 days. There is no limit on the number of caches you can store, but the total size of all caches in a repository is limited{% if actions-cache-policy-apis %}. By default, the limit is 10 GB per repository, but this limit might be different depending on policies set by your enterprise owners or repository administrators.{% else %} to 10 GB.{% endif %}
|
||||
|
||||
{% data reusables.actions.cache-eviction-process %}
|
||||
|
||||
{% if actions-cache-policy-apis %}
|
||||
For information on changing the policies for the repository cache size limit, see "[Enforcing policies for {% data variables.product.prodname_actions %} in your enterprise](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#enforcing-a-policy-for-cache-storage-in-your-enterprise)" and "[Managing {% data variables.product.prodname_actions %} settings for a repository](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#configuring-cache-storage-for-a-repository)."
|
||||
{% endif %}
|
||||
|
||||
{% if actions-cache-management %}
|
||||
|
||||
|
|
|
@ -27,11 +27,11 @@ children:
|
|||
- /workflow-syntax-for-github-actions
|
||||
- /workflow-commands-for-github-actions
|
||||
- /reusing-workflows
|
||||
- /caching-dependencies-to-speed-up-workflows
|
||||
- /storing-workflow-data-as-artifacts
|
||||
- /creating-starter-workflows-for-your-organization
|
||||
- /using-starter-workflows
|
||||
- /sharing-workflows-secrets-and-runners-with-your-organization
|
||||
- /caching-dependencies-to-speed-up-workflows
|
||||
- /storing-workflow-data-as-artifacts
|
||||
- /using-github-cli-in-workflows
|
||||
---
|
||||
|
||||
|
|
|
@ -56,6 +56,14 @@ To share data between jobs:
|
|||
|
||||
The steps of a job share the same environment on the runner machine, but run in their own individual processes. To pass data between steps in a job, you can use inputs and outputs. For more information about inputs and outputs, see "[Metadata syntax for {% data variables.product.prodname_actions %}](/articles/metadata-syntax-for-github-actions)."
|
||||
|
||||
{% if actions-caching %}
|
||||
|
||||
{% data reusables.actions.comparing-artifacts-caching %}
|
||||
|
||||
For more information on dependency caching, see "[Caching dependencies to speed up workflows](/actions/using-workflows/caching-dependencies-to-speed-up-workflows#comparing-artifacts-and-dependency-caching)."
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Uploading build and test artifacts
|
||||
|
||||
You can create a continuous integration (CI) workflow to build and test your code. For more information about using {% data variables.product.prodname_actions %} to perform CI, see "[About continuous integration](/articles/about-continuous-integration)."
|
||||
|
|
|
@ -30,7 +30,8 @@ Feature | Description | More information |
|
|||
------- | ----------- | ---------------- |{% ifversion ghes %}
|
||||
Automatic user license sync | Manage license usage across your {% data variables.product.prodname_enterprise %} deployments by automatically syncing user licenses from {% data variables.product.product_location %} to {% data variables.product.prodname_ghe_cloud %}. | "[Enabling automatic user license sync for your enterprise](/admin/configuration/configuring-github-connect/enabling-automatic-user-license-sync-for-your-enterprise)"{% endif %}{% ifversion ghes or ghae-issue-4864 %}
|
||||
{% data variables.product.prodname_dependabot %} | Allow users to find and fix vulnerabilities in code dependencies. | "[Enabling {% data variables.product.prodname_dependabot %} for your enterprise](/admin/configuration/configuring-github-connect/enabling-dependabot-for-your-enterprise)"{% endif %}
|
||||
{% data variables.product.prodname_dotcom_the_website %} actions | Allow users to use actions from {% data variables.product.prodname_dotcom_the_website %} in workflow files. | "[Enabling automatic access to {% data variables.product.prodname_dotcom_the_website %} actions using {% data variables.product.prodname_github_connect %}](/admin/github-actions/managing-access-to-actions-from-githubcom/enabling-automatic-access-to-githubcom-actions-using-github-connect)"
|
||||
{% data variables.product.prodname_dotcom_the_website %} actions | Allow users to use actions from {% data variables.product.prodname_dotcom_the_website %} in workflow files. | "[Enabling automatic access to {% data variables.product.prodname_dotcom_the_website %} actions using {% data variables.product.prodname_github_connect %}](/admin/github-actions/managing-access-to-actions-from-githubcom/enabling-automatic-access-to-githubcom-actions-using-github-connect)"{% if server-statistics %}
|
||||
{% data variables.product.prodname_server_statistics %} | Analyze your own aggregate data from GitHub Enterprise Server, and help us improve GitHub products. | "[Enabling {% data variables.product.prodname_server_statistics %} for your enterprise](/admin/configuration/configuring-github-connect/enabling-server-statistics-for-your-enterprise)"{% endif %}
|
||||
Unified search | Allow users to include repositories on {% data variables.product.prodname_dotcom_the_website %} in their search results when searching from {% data variables.product.product_location %}. | "[Enabling {% data variables.product.prodname_unified_search %} for your enterprise](/admin/configuration/configuring-github-connect/enabling-unified-search-for-your-enterprise)"
|
||||
Unified contributions | Allow users to include anonymized contribution counts for their work on {% data variables.product.product_location %} in their contribution graphs on {% data variables.product.prodname_dotcom_the_website %}. | "[Enabling {% data variables.product.prodname_unified_contributions %} for your enterprise](/admin/configuration/configuring-github-connect/enabling-unified-contributions-for-your-enterprise)"
|
||||
|
||||
|
@ -66,7 +67,8 @@ Feature | Data | Which way does the data flow? | Where is the data used? |
|
|||
Automatic user license sync | Each {% data variables.product.product_name %} user's user ID and email addresses | From {% data variables.product.product_name %} to {% data variables.product.prodname_ghe_cloud %} | {% data variables.product.prodname_ghe_cloud %} |{% endif %}{% ifversion ghes or ghae-issue-4864 %}
|
||||
{% data variables.product.prodname_dependabot_alerts %} | Vulnerability alerts | From {% data variables.product.prodname_dotcom_the_website %} to {% data variables.product.product_name %} | {% data variables.product.product_name %} |{% endif %}{% if dependabot-updates-github-connect %}
|
||||
{% data variables.product.prodname_dependabot_updates %} | Dependencies and the metadata for each dependency's repository<br><br>If a dependency is stored in a private repository on {% data variables.product.prodname_dotcom_the_website %}, data will only be transmitted if {% data variables.product.prodname_dependabot %} is configured and authorized to access that repository. | From {% data variables.product.prodname_dotcom_the_website %} to {% data variables.product.product_name %} | {% data variables.product.product_name %} {% endif %}
|
||||
{% data variables.product.prodname_dotcom_the_website %} actions | Name of action, action (YAML file from {% data variables.product.prodname_marketplace %}) | From {% data variables.product.prodname_dotcom_the_website %} to {% data variables.product.product_name %}<br><br>From {% data variables.product.product_name %} to {% data variables.product.prodname_dotcom_the_website %} | {% data variables.product.product_name %}
|
||||
{% data variables.product.prodname_dotcom_the_website %} actions | Name of action, action (YAML file from {% data variables.product.prodname_marketplace %}) | From {% data variables.product.prodname_dotcom_the_website %} to {% data variables.product.product_name %}<br><br>From {% data variables.product.product_name %} to {% data variables.product.prodname_dotcom_the_website %} | {% data variables.product.product_name %}{% if server-statistics %}
|
||||
{% data variables.product.prodname_server_statistics %} | Aggregate {% data variables.product.prodname_ghe_server %} usage metrics<br>For the list of aggregate metrics collected, see "[{% data variables.product.prodname_server_statistics %} data collected](/admin/monitoring-activity-in-your-enterprise/analyzing-how-your-team-works-with-server-statistics/about-server-statistics#server-statistics-data-collected)." | From {% data variables.product.product_name %} to {% data variables.product.prodname_ghe_cloud %} | {% data variables.product.prodname_ghe_cloud %}{% endif %}
|
||||
Unified search | Search terms, search results | From {% data variables.product.prodname_dotcom_the_website %} to {% data variables.product.product_name %}<br><br>From {% data variables.product.product_name %} to {% data variables.product.prodname_dotcom_the_website %} | {% data variables.product.product_name %} |
|
||||
Unified contributions | Contribution counts | From {% data variables.product.product_name %} to {% data variables.product.prodname_dotcom_the_website %} | {% data variables.product.prodname_dotcom_the_website %} |
|
||||
|
||||
|
|
|
@ -21,7 +21,7 @@ shortTitle: Automatic user license sync
|
|||
|
||||
{% data reusables.enterprise-licensing.about-license-sync %} For more information, see "[About {% data variables.product.prodname_github_connect %}](/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.
|
||||
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 "[Triggering a license sync job](/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 organization or enterprise account on {% data variables.product.prodname_ghe_cloud %}.
|
||||
|
||||
|
|
|
@ -0,0 +1,32 @@
|
|||
---
|
||||
title: Enabling Server Statistics for your enterprise
|
||||
intro: 'You can analyze your own aggregate data from {% data variables.product.prodname_ghe_server %} and help us improve {% data variables.product.company_short %} products by enabling {% data variables.product.prodname_server_statistics %}.'
|
||||
versions:
|
||||
feature: 'server-statistics'
|
||||
redirect_from:
|
||||
- /early-access/github/analyze-how-your-team-works-with-server-statistics/about-server-statistics/enabling-server-statistics
|
||||
topics:
|
||||
- Enterprise
|
||||
shortTitle: Server Statistics
|
||||
---
|
||||
|
||||
{% data reusables.server-statistics.release-phase %}
|
||||
|
||||
## About {% data variables.product.prodname_server_statistics %}
|
||||
|
||||
{% data variables.product.prodname_server_statistics %} collects aggregate usage data from {% data variables.product.product_location %}, which you can use to better anticipate the needs of your organization, understand how your team works, and show the value you get from {% data variables.product.prodname_ghe_server %}.
|
||||
|
||||
{% data variables.product.prodname_server_statistics %} only collects certain aggregate metrics on repositories, issues, pull requests, and other features.{% data variables.product.prodname_dotcom %} content, such as code, issues, comments, or pull request content, is not collected. For more information, see "[About {% data variables.product.prodname_server_statistics %}](/admin/monitoring-activity-in-your-enterprise/analyzing-how-your-team-works-with-server-statistics/about-server-statistics)."
|
||||
|
||||
By enabling {% data variables.product.prodname_server_statistics %}, you are also helping to improve {% data variables.product.company_short %}. The aggregated data you will provide helps us understand how our customers are using {% data variables.product.prodname_dotcom %}, and make better and more informed product decisions, ultimately benefiting you.
|
||||
|
||||
## Enabling {% data variables.product.prodname_server_statistics %}
|
||||
|
||||
Before you can enable {% data variables.product.prodname_server_statistics %}, you must first connect your {% data variables.product.prodname_ghe_server %} instance to {% data variables.product.prodname_dotcom_the_website %} through {% data variables.product.prodname_github_connect %}. For more information, see "[Connecting {% data variables.product.prodname_ghe_server %} to {% data variables.product.prodname_ghe_cloud %}](/enterprise-server@3.1/admin/configuration/managing-connections-between-github-enterprise-server-and-github-enterprise-cloud/connecting-github-enterprise-server-to-github-enterprise-cloud)."
|
||||
|
||||
You can disable {% data variables.product.prodname_server_statistics %} from {% data variables.product.prodname_ghe_server %} at any time.
|
||||
|
||||
{% data reusables.enterprise-accounts.access-enterprise %}
|
||||
{% data reusables.enterprise-accounts.github-connect-tab %}
|
||||
4. Under "Share server statistics with GitHub.com", select the dropdown menu and click **Enabled** or **Disabled**.
|
||||
![Screenshot of {% data variables.product.prodname_server_statistics %} drop-down menu with disabled or enabled options](/assets/images/help/server-statistics/server-statistics-enable-disable-options.png)
|
|
@ -21,6 +21,7 @@ children:
|
|||
- /managing-github-connect
|
||||
- /enabling-automatic-user-license-sync-for-your-enterprise
|
||||
- /enabling-dependabot-for-your-enterprise
|
||||
- /enabling-server-statistics-for-your-enterprise
|
||||
- /enabling-unified-search-for-your-enterprise
|
||||
- /enabling-unified-contributions-for-your-enterprise
|
||||
shortTitle: GitHub Connect
|
||||
|
|
|
@ -39,7 +39,8 @@ When subdomain isolation is enabled, {% data variables.product.prodname_ghe_serv
|
|||
| `https://HOSTNAME/_registry/npm/` | `https://npm.HOSTNAME/`
|
||||
| `https://HOSTNAME/_registry/rubygems/` | `https://rubygems.HOSTNAME/`
|
||||
| `https://HOSTNAME/_registry/maven/` | `https://maven.HOSTNAME/`
|
||||
| `https://HOSTNAME/_registry/nuget/` | `https://nuget.HOSTNAME/`{% endif %}
|
||||
| `https://HOSTNAME/_registry/nuget/` | `https://nuget.HOSTNAME/`{% endif %}{% ifversion ghes > 3.4 %}
|
||||
| Not supported | `https://containers.HOSTNAME/` |{% endif %}
|
||||
|
||||
## Prerequisites
|
||||
|
||||
|
|
|
@ -209,7 +209,7 @@ ghe-logs-tail
|
|||
|
||||
### ghe-maintenance
|
||||
|
||||
This utility allows you to control the state of the installation's maintenance mode. It's designed to be used primarily by the {% data variables.enterprise.management_console %} behind-the-scenes, but it can be used directly.
|
||||
This utility allows you to control the state of the installation's maintenance mode. It's designed to be used primarily by the {% data variables.enterprise.management_console %} behind-the-scenes, but it can be used directly. For more information, see "[Enabling and scheduling maintenance mode](/admin/guides/installation/enabling-and-scheduling-maintenance-mode)."
|
||||
|
||||
```shell
|
||||
ghe-maintenance -h
|
||||
|
|
|
@ -129,6 +129,10 @@ $ ghe-restore -c 169.154.1.1
|
|||
> Visit https://169.154.1.1/setup/settings to review appliance configuration.
|
||||
```
|
||||
|
||||
{% if ip-exception-list %}
|
||||
Optionally, to validate the restore, configure an IP exception list to allow access to a specified list of IP addresses. For more information, see "[Validating changes in maintenance mode using the IP exception list](/admin/configuration/configuring-your-enterprise/enabling-and-scheduling-maintenance-mode#validating-changes-in-maintenance-mode-using-the-ip-exception-list)."
|
||||
{% endif %}
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** The network settings are excluded from the backup snapshot. You must manually configure the network on the target {% data variables.product.prodname_ghe_server %} appliance as required for your environment.
|
||||
|
|
|
@ -25,12 +25,7 @@ Enterprise owners can configure email for notifications.
|
|||
## Configuring SMTP for your enterprise
|
||||
|
||||
{% ifversion ghes %}
|
||||
{% data reusables.enterprise_site_admin_settings.access-settings %}
|
||||
{% data reusables.enterprise_site_admin_settings.management-console %}
|
||||
2. At the top of the page, click **Settings**.
|
||||
![Settings tab](/assets/images/enterprise/management-console/settings-tab.png)
|
||||
3. In the left sidebar, click **Email**.
|
||||
![Email tab](/assets/images/enterprise/management-console/email-sidebar.png)
|
||||
{% data reusables.enterprise_site_admin_settings.email-settings %}
|
||||
4. Select **Enable email**. This will enable both outbound and inbound email, however for inbound email to work you will also need to configure your DNS settings as described below in "[Configuring DNS and firewall
|
||||
settings to allow incoming emails](#configuring-dns-and-firewall-settings-to-allow-incoming-emails)."
|
||||
![Enable outbound email](/assets/images/enterprise/management-console/enable-outbound-email.png)
|
||||
|
|
|
@ -0,0 +1,76 @@
|
|||
---
|
||||
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'
|
||||
type: how_to
|
||||
topics:
|
||||
- Access management
|
||||
- Enterprise
|
||||
- Fundamentals
|
||||
- Identity
|
||||
- Security
|
||||
permissions: Site administrators can configure web commit signing for {% data variables.product.product_location %}.
|
||||
---
|
||||
|
||||
## About web commit signing
|
||||
|
||||
If you enable web commit signing, {% data variables.product.product_name %} will automatically use GPG to sign commits users make on the web interface of {% data variables.product.product_location %}. Commits signed by {% data variables.product.product_name %} will have a verified status. For more information, see "[About commit signature verification](/authentication/managing-commit-signature-verification/about-commit-signature-verification)."
|
||||
|
||||
You can enable web commit signing, rotate the private key used for web commit signing, and disable web commit signing.
|
||||
|
||||
## Enabling web commit signing
|
||||
|
||||
{% data reusables.enterprise_site_admin_settings.create-pgp-key-web-commit-signing %}
|
||||
- If you have a no-reply email address defined in the {% data variables.enterprise.management_console %}, use that email address. If not, use any email address, such as `web-flow@my-company.com`. The email address does not need to be valid.
|
||||
{% data reusables.enterprise_site_admin_settings.pgp-key-no-passphrase %}
|
||||
{% data reusables.enterprise_site_admin_settings.pgp-key-env-variable %}
|
||||
{% data reusables.enterprise_site_admin_settings.update-commit-signing-service %}
|
||||
1. Enable web commit signing.
|
||||
|
||||
```bash{:copy}
|
||||
ghe-config app.github.web-commit-signing-enabled true
|
||||
```
|
||||
1. Apply the configuration, then wait for the configuration run to complete.
|
||||
|
||||
```bash{:copy}
|
||||
ghe-config-apply
|
||||
```
|
||||
1. Create a new user on {% data variables.product.product_location %} via built-in authentication or external authentication. For more information, see "[About authentication for your enterprise](/admin/identity-and-access-management/managing-iam-for-your-enterprise/about-authentication-for-your-enterprise)."
|
||||
- The user's username must be `web-flow`.
|
||||
- The user's email address must be the same address you used for the PGP key.
|
||||
{% data reusables.enterprise_site_admin_settings.add-key-to-web-flow-user %}
|
||||
{% data reusables.enterprise_site_admin_settings.email-settings %}
|
||||
1. Under "No-reply email address", type the same email address you used for the PGP key.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** The "No-reply email address" field will only be displayed if you've enabled email for {% data variables.product.product_location %}. For more information, see "[Configuring email for notifications](/admin/configuration/configuring-your-enterprise/configuring-email-for-notifications#configuring-smtp-for-your-enterprise)."
|
||||
|
||||
{% endnote %}
|
||||
{% data reusables.enterprise_management_console.save-settings %}
|
||||
|
||||
## Rotating the private key used for web commit signing
|
||||
|
||||
{% data reusables.enterprise_site_admin_settings.create-pgp-key-web-commit-signing %}
|
||||
- Use the no-reply email address defined in the {% data variables.enterprise.management_console %}, which should be the same as the email address of the `web-flow` user.
|
||||
{% data reusables.enterprise_site_admin_settings.pgp-key-no-passphrase %}
|
||||
{% data reusables.enterprise_site_admin_settings.pgp-key-env-variable %}
|
||||
{% data reusables.enterprise_site_admin_settings.update-commit-signing-service %}
|
||||
{% data reusables.enterprise_site_admin_settings.add-key-to-web-flow-user %}
|
||||
|
||||
## Disabling web commit signing
|
||||
|
||||
You can disable web commit signing for {% data variables.product.product_location %}.
|
||||
|
||||
1. In the administrative shell, run the following command.
|
||||
|
||||
```bash{:copy}
|
||||
ghe-config app.github.web-commit-signing-enabled false
|
||||
```
|
||||
1. Apply the configuration.
|
||||
|
||||
```bash{:copy}
|
||||
ghe-config-apply
|
||||
```
|
|
@ -32,12 +32,20 @@ Some types of operations require that you take {% data variables.product.product
|
|||
|
||||
We recommend that you schedule a maintenance window for at least 30 minutes in the future to give users time to prepare. When a maintenance window is scheduled, all users will see a banner when accessing the site.
|
||||
|
||||
|
||||
|
||||
![End user banner about scheduled maintenance](/assets/images/enterprise/maintenance/maintenance-scheduled.png)
|
||||
|
||||
When the instance is in maintenance mode, all normal HTTP and Git access is refused. Git fetch, clone, and push operations are also rejected with an error message indicating that the site is temporarily unavailable. In high availability configurations, Git replication will be paused. GitHub Actions jobs will not be executed. Visiting the site in a browser results in a maintenance page.
|
||||
|
||||
![The maintenance mode splash screen](/assets/images/enterprise/maintenance/maintenance-mode-maintenance-page.png)
|
||||
|
||||
{% if ip-exception-list %}
|
||||
|
||||
You can perform initial validation of your maintenance operation by configuring an IP exception list to allow access to {% data variables.product.product_location %} from only the IP addresses and ranges provided. Attempts to access {% data variables.product.product_location %} from IP addresses not specified on the IP exception list will receive a response consistent with those sent when the instance is in maintenance mode.
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Enabling maintenance mode immediately or scheduling a maintenance window for a later time
|
||||
|
||||
{% data reusables.enterprise_site_admin_settings.access-settings %}
|
||||
|
@ -53,6 +61,27 @@ When the instance is in maintenance mode, all normal HTTP and Git access is refu
|
|||
![Checkbox for enabling or scheduling maintenance mode](/assets/images/enterprise/maintenance/enable-maintenance-mode-checkbox.png)
|
||||
{% data reusables.enterprise_management_console.save-settings %}
|
||||
|
||||
{% if ip-exception-list %}
|
||||
|
||||
## Validating changes in maintenance mode using the IP exception list
|
||||
|
||||
The IP exception list provides controlled and restricted access to {% data variables.product.product_location %}, which is ideal for initial validation of server health following a maintenance operation. Once enabled, {% data variables.product.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.
|
||||
|
||||
If you re-enable maintenance mode, the IP exception list will be disabled and {% data variables.product.product_location %} will return to maintenance mode. If you just disable the IP exception list, {% data variables.product.product_location %} will return to normal operation.
|
||||
|
||||
{% data reusables.enterprise_site_admin_settings.access-settings %}
|
||||
{% data reusables.enterprise_site_admin_settings.management-console %}
|
||||
1. At the top of the {% data variables.enterprise.management_console %}, click **Maintenance**, and confirm maintenance mode is already enabled.
|
||||
![Maintenance tab](/assets/images/enterprise/management-console/maintenance-tab.png)
|
||||
1. Select **Enable IP exception list**.
|
||||
![Checkbox for enabling ip exception list](/assets/images/enterprise/maintenance/enable-ip-exception-list.png)
|
||||
1. In the text box, type a valid list of space-separated IP addresses or CIDR blocks that should be allowed to access {% data variables.product.product_location %}.
|
||||
![completed field for IP addresses](/assets/images/enterprise/maintenance/ip-exception-list-ip-addresses.png)
|
||||
1. Click **Save**.
|
||||
![after IP excetpion list has saved](/assets/images/enterprise/maintenance/ip-exception-save.png)
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Scheduling maintenance mode with {% data variables.product.prodname_enterprise_api %}
|
||||
|
||||
You can schedule maintenance for different times or dates with {% data variables.product.prodname_enterprise_api %}. For more information, see "[Management Console](/enterprise/{{ currentVersion }}/user/rest/reference/enterprise-admin#enable-or-disable-maintenance-mode)."
|
||||
|
|
|
@ -36,6 +36,7 @@ children:
|
|||
- /configuring-github-pages-for-your-enterprise
|
||||
- /configuring-the-referrer-policy-for-your-enterprise
|
||||
- /configuring-custom-footers
|
||||
- /configuring-web-commit-signing
|
||||
shortTitle: Configure your enterprise
|
||||
---
|
||||
|
||||
|
|
|
@ -16,6 +16,12 @@ shortTitle: Increase CPU or memory
|
|||
---
|
||||
{% data reusables.enterprise_installation.warning-on-upgrading-physical-resources %}
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** Before increasing CPU or memory resources, put your instance in maintenance mode.{% if ip-exception-list %} You can validate changes by configuring an IP exception list to allow access from specified IP addresses. {% endif %} For more information, see "[Enabling and scheduling maintenance mode](/enterprise/{{ currentVersion }}/admin/guides/installation/enabling-and-scheduling-maintenance-mode)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
## Adding CPU or memory resources for AWS
|
||||
|
||||
{% note %}
|
||||
|
|
|
@ -23,7 +23,7 @@ As more users join {% data variables.product.product_location %}, you may need t
|
|||
|
||||
{% note %}
|
||||
|
||||
**Note:** Before resizing any storage volume, put your instance in maintenance mode. For more information, see "[Enabling and scheduling maintenance mode](/enterprise/{{ currentVersion }}/admin/guides/installation/enabling-and-scheduling-maintenance-mode)."
|
||||
**Note:** Before resizing any storage volume, put your instance in maintenance mode.{% if ip-exception-list %} You can validate changes by configuring an IP exception list to allow access from specified IP addresses. {% endif %} For more information, see "[Enabling and scheduling maintenance mode](/enterprise/{{ currentVersion }}/admin/guides/installation/enabling-and-scheduling-maintenance-mode)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
|
|
|
@ -176,6 +176,9 @@ While you can use a hotpatch to upgrade to the latest patch release within a fea
|
|||
Target root partition: /dev/xvda2
|
||||
Proceed with installation? [y/N]
|
||||
```
|
||||
{% if ip-exception-list %}
|
||||
1. Optionally, to validate the upgrade, configure an IP exception list to allow access to a specified list of IP addresses. For more information, see "[Validating changes in maintenance mode using the IP exception list](/admin/configuration/configuring-your-enterprise/enabling-and-scheduling-maintenance-mode#validating-changes-in-maintenance-mode-using-the-ip-exception-list)."
|
||||
{% endif %}
|
||||
7. For single appliance upgrades, disable maintenance mode so users can use {% data variables.product.product_location %}.
|
||||
|
||||
{% note %}
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Enabling GitHub Actions with Amazon S3 storage
|
||||
intro: 'You can enable {% data variables.product.prodname_actions %} on {% data variables.product.prodname_ghe_server %} and use Amazon S3 storage to store artifacts generated by workflow runs.'
|
||||
intro: 'You can enable {% data variables.product.prodname_actions %} on {% data variables.product.prodname_ghe_server %} and use Amazon S3 storage to store data generated by workflow runs.'
|
||||
permissions: 'Site administrators can enable {% data variables.product.prodname_actions %} and configure enterprise settings.'
|
||||
versions:
|
||||
ghes: '*'
|
||||
|
@ -20,7 +20,7 @@ shortTitle: Amazon S3 storage
|
|||
|
||||
Before enabling {% data variables.product.prodname_actions %}, make sure you have completed the following steps:
|
||||
|
||||
* Create your Amazon S3 bucket for storing artifacts generated by workflow runs. {% indented_data_reference reusables.actions.enterprise-s3-permission spaces=2 %}
|
||||
* Create your Amazon S3 bucket for storing data generated by workflow runs. {% indented_data_reference reusables.actions.enterprise-s3-permission spaces=2 %}
|
||||
|
||||
{% data reusables.actions.enterprise-common-prereqs %}
|
||||
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Enabling GitHub Actions with Azure Blob storage
|
||||
intro: 'You can enable {% data variables.product.prodname_actions %} on {% data variables.product.prodname_ghe_server %} and use Azure Blob storage to store artifacts generated by workflow runs.'
|
||||
intro: 'You can enable {% data variables.product.prodname_actions %} on {% data variables.product.prodname_ghe_server %} and use Azure Blob storage to store data generated by workflow runs.'
|
||||
permissions: 'Site administrators can enable {% data variables.product.prodname_actions %} and configure enterprise settings.'
|
||||
versions:
|
||||
ghes: '*'
|
||||
|
@ -18,7 +18,7 @@ shortTitle: Azure Blob storage
|
|||
|
||||
Before enabling {% data variables.product.prodname_actions %}, make sure you have completed the following steps:
|
||||
|
||||
* Create your Azure storage account for storing workflow artifacts. {% data variables.product.prodname_actions %} stores its data as block blobs, and two storage account types are supported:
|
||||
* Create your Azure storage account for storing workflow data. {% data variables.product.prodname_actions %} stores its data as block blobs, and two storage account types are supported:
|
||||
* A **general-purpose** storage account (also known as `general-purpose v1` or `general-purpose v2`) using the **standard** performance tier.
|
||||
|
||||
{% warning %}
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Enabling GitHub Actions with MinIO Gateway for NAS storage
|
||||
intro: 'You can enable {% data variables.product.prodname_actions %} on {% data variables.product.prodname_ghe_server %} and use MinIO Gateway for NAS storage to store artifacts generated by workflow runs.'
|
||||
intro: 'You can enable {% data variables.product.prodname_actions %} on {% data variables.product.prodname_ghe_server %} and use MinIO Gateway for NAS storage to store data generated by workflow runs.'
|
||||
permissions: 'Site administrators can enable {% data variables.product.prodname_actions %} and configure enterprise settings.'
|
||||
versions:
|
||||
ghes: '*'
|
||||
|
@ -26,7 +26,7 @@ shortTitle: MinIO Gateway for NAS storage
|
|||
Before enabling {% data variables.product.prodname_actions %}, make sure you have completed the following steps:
|
||||
|
||||
* To avoid resource contention on the appliance, we recommend that MinIO be hosted separately from {% data variables.product.product_location %}.
|
||||
* Create your bucket for storing workflow artifacts. To set up your bucket and access key, see the [MinIO documentation](https://docs.min.io/docs/minio-gateway-for-nas.html). {% indented_data_reference reusables.actions.enterprise-s3-permission spaces=2 %}
|
||||
* Create your bucket for storing workflow data. To set up your bucket and access key, see the [MinIO documentation](https://docs.min.io/docs/minio-gateway-for-nas.html). {% indented_data_reference reusables.actions.enterprise-s3-permission spaces=2 %}
|
||||
|
||||
{% data reusables.actions.enterprise-common-prereqs %}
|
||||
|
||||
|
|
|
@ -39,7 +39,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 %}"[About {% data variables.product.company_short %}-hosted runners](/actions/using-github-hosted-runners/about-github-hosted-runners)" and{% endif %} "[About self-hosted runners](/actions/hosting-your-own-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 ghae-issue-4856 %} 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 "[About security hardening with OpenID Connect](/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 ghae-issue-4856 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 "[About security hardening with OpenID Connect](/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 "[Enforcing policies for {% data variables.product.prodname_actions %} in your enterprise](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise)."
|
||||
|
||||
|
|
|
@ -25,7 +25,7 @@ This article explains how site administrators can configure {% data variables.pr
|
|||
|
||||
{% data reusables.enterprise.upgrade-ghes-for-actions %}
|
||||
|
||||
{% data reusables.actions.ghes-actions-not-enabled-by-default %} You'll need to determine whether your instance has adequate CPU and memory resources to handle the load from {% data variables.product.prodname_actions %} without causing performance loss, and possibly increase those resources. You'll also need to decide which storage provider you'll use for the blob storage required to store artifacts generated by workflow runs. Then, you'll enable {% data variables.product.prodname_actions %} for your enterprise, manage access permissions, and add self-hosted runners to run workflows.
|
||||
{% data reusables.actions.ghes-actions-not-enabled-by-default %} You'll need to determine whether your instance has adequate CPU and memory resources to handle the load from {% data variables.product.prodname_actions %} without causing performance loss, and possibly increase those resources. You'll also need to decide which storage provider you'll use for the blob storage required to store artifacts{% if actions-caching %} and caches{% endif %} generated by workflow runs. Then, you'll enable {% data variables.product.prodname_actions %} for your enterprise, manage access permissions, and add self-hosted runners to run workflows.
|
||||
|
||||
{% data reusables.actions.introducing-enterprise %}
|
||||
|
||||
|
@ -104,7 +104,7 @@ Optionally, you can limit resource consumption on {% data variables.product.prod
|
|||
|
||||
To enable {% data variables.product.prodname_actions %} on {% data variables.product.prodname_ghe_server %}, you must have access to external blob storage.
|
||||
|
||||
{% data variables.product.prodname_actions %} uses blob storage to store artifacts generated by workflow runs, such as workflow logs and user-uploaded build artifacts. The amount of storage required depends on your usage of {% data variables.product.prodname_actions %}. Only a single external storage configuration is supported, and you can't use multiple storage providers at the same time.
|
||||
{% data variables.product.prodname_actions %} uses blob storage to store data generated by workflow runs, such as workflow logs{% if actions-caching %}, caches,{% endif %} and user-uploaded build artifacts. The amount of storage required depends on your usage of {% data variables.product.prodname_actions %}. Only a single external storage configuration is supported, and you can't use multiple storage providers at the same time.
|
||||
|
||||
{% data variables.product.prodname_actions %} supports these storage providers:
|
||||
|
||||
|
|
|
@ -110,22 +110,20 @@ Finally, you should consider security hardening for self-hosted runners. For mor
|
|||
|
||||
### Storage
|
||||
|
||||
{% data reusables.actions.about-artifacts %} For more information, see "[Storing workflow data as artifacts](/actions/advanced-guides/storing-workflow-data-as-artifacts)."
|
||||
{% data reusables.actions.about-artifacts %} For more information, see "[Storing workflow data as artifacts](/actions/advanced-guides/storing-workflow-data-as-artifacts)."
|
||||
|
||||
![Screenshot of artifact](/assets/images/help/repository/passing-data-between-jobs-in-a-workflow-updated.png)
|
||||
{% if actions-caching %}{% data variables.product.prodname_actions %} also has a caching system that you can use to cache dependencies to speed up workflow runs. For more information, see "[Caching dependencies to speed up workflows](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)."{% endif %}
|
||||
|
||||
{% ifversion ghes %}
|
||||
You must configure external blob storage for these artifacts. Decide which supported storage provider your enterprise will use. For more information, see "[Getting started with {% data variables.product.prodname_actions %} for {% data variables.product.product_name %}](/admin/github-actions/getting-started-with-github-actions-for-your-enterprise/getting-started-with-github-actions-for-github-enterprise-server#external-storage-requirements)."
|
||||
You must configure external blob storage for workflow artifacts{% if actions-caching %}, caches,{% endif %} and other workflow logs. Decide which supported storage provider your enterprise will use. For more information, see "[Getting started with {% data variables.product.prodname_actions %} for {% data variables.product.product_name %}](/admin/github-actions/getting-started-with-github-actions-for-your-enterprise/getting-started-with-github-actions-for-github-enterprise-server#external-storage-requirements)."
|
||||
{% endif %}
|
||||
|
||||
{% ifversion ghec or ghes %}
|
||||
|
||||
{% data reusables.actions.artifact-log-retention-statement %}
|
||||
You can use policy settings for {% data variables.product.prodname_actions %} to customize the storage of workflow artifacts{% if actions-caching %}, caches,{% endif %} and log retention. For more information, see "[Enforcing policies for {% data variables.product.prodname_actions %} in your enterprise](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise)."
|
||||
|
||||
{% endif %}
|
||||
|
||||
If you want to retain logs and artifacts longer than the upper limit you can configure in {% data variables.product.product_name %}, you'll have to plan how to export and store the data.
|
||||
|
||||
{% ifversion ghec %}
|
||||
Some storage is included in your subscription, but additional storage will affect your bill. You should plan for this cost. For more information, see "[About billing for {% data variables.product.prodname_actions %}](/billing/managing-billing-for-github-actions/about-billing-for-github-actions)."
|
||||
{% endif %}
|
||||
|
|
|
@ -0,0 +1,102 @@
|
|||
---
|
||||
title: About Server Statistics
|
||||
intro: 'You can use {% data variables.product.prodname_server_statistics %} to analyze your own aggregate data from {% data variables.product.prodname_ghe_server %}, and help us improve {% data variables.product.company_short %} products.'
|
||||
versions:
|
||||
feature: 'server-statistics'
|
||||
permissions: 'Enterprise owners can enable {% data variables.product.prodname_server_statistics %}.'
|
||||
redirect_from:
|
||||
- /early-access/github/analyze-how-your-team-works-with-server-statistics/about-server-statistics
|
||||
topics:
|
||||
- Enterprise
|
||||
---
|
||||
|
||||
{% data reusables.server-statistics.release-phase %}
|
||||
|
||||
## About the benefits of {% data variables.product.prodname_server_statistics %}
|
||||
|
||||
{% data variables.product.prodname_server_statistics %} can help you anticipate the needs of your organization, understand how your team works, and show the value you get from {% data variables.product.prodname_ghe_server %}.
|
||||
|
||||
Once enabled, {% data variables.product.prodname_server_statistics %} collects aggregate data on how much certain features are used on your instance over time. Unlike other [Admin Stats API](/rest/reference/enterprise-admin#admin-stats) endpoints, which only return data for the last day, {% data variables.product.prodname_server_statistics %} provides historical data of all {% data variables.product.prodname_server_statistics %} metrics collected since the day you enabled the feature. For more information, see "[Enabling {% data variables.product.prodname_server_statistics %} for your enterprise](/admin/configuration/configuring-github-connect/enabling-server-statistics-for-your-enterprise)."
|
||||
|
||||
When you enable {% data variables.product.prodname_server_statistics %}, you're helping to build a better {% data variables.product.prodname_dotcom %}. The aggregated data you'll provide gives us insights into how {% data variables.product.prodname_dotcom %} adds value to our customers. This information allows {% data variables.product.company_short %} to make better and more informed product decisions, ultimately benefiting you.
|
||||
|
||||
## About data security
|
||||
|
||||
We respect your data. We will never transmit data from {% data variables.product.product_location %} unless you have first given us permission to do so.
|
||||
|
||||
We collect no personal data. We also don't collect any {% data variables.product.company_short %} content, such as code, issues, comments, or pull request content.
|
||||
|
||||
Only owners of the connected enterprise account or organization on {% data variables.product.prodname_ghe_cloud %} can access the data.
|
||||
|
||||
Only certain aggregate metrics are collected on repositories, issues, pull requests, and other features. To see the list of aggregate metrics collected, see "[{% data variables.product.prodname_server_statistics %} data collected](#server-statistics-data-collected)."
|
||||
|
||||
Any updates to the collected metrics will happen in future feature releases of {% data variables.product.prodname_ghe_server %} and will be described in the [{% data variables.product.prodname_ghe_server %} release notes](/admin/release-notes). In addition, we will update this article with all metric updates.
|
||||
|
||||
For a better understanding of how we store and secure {% data variables.product.prodname_server_statistics %} data, see "[GitHub Security](https://github.com/security)."
|
||||
|
||||
### About data retention and deletion
|
||||
|
||||
{% data variables.product.company_short %} collects {% data variables.product.prodname_server_statistics %} data for as long as your {% data variables.product.prodname_ghe_server %} license is active and the {% data variables.product.prodname_server_statistics %} feature is enabled.
|
||||
|
||||
If you would like to delete your data, you may do so by contacting GitHub Support, your {% data variables.product.prodname_dotcom %} account representative, or your Customer Success Manager. Generally, we delete data in the timeframe specified in our privacy statement. For more information, see [{% data variables.product.company_short %}'s privacy statement](/free-pro-team@latest/site-policy/privacy-policies/github-privacy-statement#data-retention-and-deletion-of-data) in the {% data variables.product.prodname_dotcom_the_website %} documentation.
|
||||
|
||||
### About data portability
|
||||
|
||||
As an organization owner or enterprise owner on {% data variables.product.prodname_ghe_cloud %}, you can access {% data variables.product.prodname_server_statistics %} data by exporting the data in a CSV or JSON file or through the {% data variables.product.prodname_server_statistics %} REST API. For more information, see "[Requesting {% data variables.product.prodname_server_statistics %} using the REST API](/admin/monitoring-activity-in-your-enterprise/analyzing-how-your-team-works-with-server-statistics/requesting-server-statistics-using-the-rest-api)" or "[Exporting {% data variables.product.prodname_server_statistics %}](/admin/monitoring-activity-in-your-enterprise/analyzing-how-your-team-works-with-server-statistics/exporting-server-statistics)."
|
||||
|
||||
## About disabling data collection
|
||||
|
||||
You can disable the {% data variables.product.prodname_server_statistics %} feature at any time. For more information, see "[Enabling {% data variables.product.prodname_server_statistics %} for your enterprise](/admin/configuration/configuring-github-connect/enabling-server-statistics-for-your-enterprise)."
|
||||
|
||||
## {% data variables.product.prodname_server_statistics %} data collected
|
||||
|
||||
After you enable {% data variables.product.prodname_server_statistics %}, metrics are collected through a daily job that runs on {% data variables.product.product_location %}. The aggregate metrics are stored on your organization or enterprise account on {% data variables.product.prodname_ghe_cloud %} and are not stored on {% data variables.product.product_location %}.
|
||||
|
||||
The following aggregate metrics will be collected and transmitted on a daily basis and represent the total counts for the day:
|
||||
- `active_hooks`
|
||||
- `admin_users`
|
||||
- `closed_issues`
|
||||
- `closed_milestones`
|
||||
- `collection_date`
|
||||
- `disabled_orgs`
|
||||
- `dormancy_threshold`
|
||||
- `fork_repos`
|
||||
- `ghes_version`
|
||||
- `github_connect_features_enabled`
|
||||
- `inactive_hooks`
|
||||
- `mergeable_pulls`
|
||||
- `merged_pulls`
|
||||
- `open_issues`
|
||||
- `open_milestones`
|
||||
- `org_repos`
|
||||
- `private_gists`
|
||||
- `public_gists`
|
||||
- `root_repos`
|
||||
- `schema_version`
|
||||
- `server_id`
|
||||
- `suspended_users`
|
||||
- `total_commit_comments`
|
||||
- `total_dormant_users`
|
||||
- `total_gist_comments`
|
||||
- `total_gists`
|
||||
- `total_hooks`
|
||||
- `total_issues`
|
||||
- `total_issue_comments`
|
||||
- `total_milestones`
|
||||
- `total_repos`
|
||||
- `total_orgs`
|
||||
- `total_pages`
|
||||
- `total_pull_request_comments`
|
||||
- `total_pulls`
|
||||
- `total_pushes`
|
||||
- `total_team_members`
|
||||
- `total_teams`
|
||||
- `total_users`
|
||||
- `total_wikis`
|
||||
- `unmergeable_pulls`
|
||||
|
||||
## {% data variables.product.prodname_server_statistics %} payload example
|
||||
|
||||
To see an example of the response payload for the {% data variables.product.prodname_server_statistics %} API, see "[Requesting {% data variables.product.prodname_server_statistics %} using the REST API](/admin/monitoring-activity-in-your-enterprise/analyzing-how-your-team-works-with-server-statistics/requesting-server-statistics-using-the-rest-api)."
|
||||
|
||||
To see a list of the data collected, see "[{% data variables.product.prodname_server_statistics %} data collected](#server-statistics-data-collected)."
|
|
@ -0,0 +1,49 @@
|
|||
---
|
||||
title: Exporting Server Statistics
|
||||
shortTitle: Export Server Statistics
|
||||
intro: 'You can use your own tools to analyze your {% data variables.product.prodname_ghe_server %} usage over time by downloading your {% data variables.product.prodname_server_statistics %} metrics in a CSV or JSON file.'
|
||||
versions:
|
||||
feature: 'server-statistics'
|
||||
redirect_from:
|
||||
- /early-access/github/analyze-how-your-team-works-with-server-statistics/exploring-server-statistics
|
||||
---
|
||||
|
||||
{% data reusables.server-statistics.release-phase %}
|
||||
|
||||
You can download up to the last 365 days of {% data variables.product.prodname_server_statistics %} data in a CSV or JSON file. This data, which includes aggregate metrics on repositories, issues, and pull requests, can help you anticipate the needs of your organization, understand how your team works, and show the value you get from {% data variables.product.prodname_ghe_server %}.
|
||||
|
||||
Before you can download this data, you must enable {% data variables.product.prodname_server_statistics %}. For more information, see "[Enabling {% data variables.product.prodname_server_statistics %} for your enterprise](/admin/configuration/configuring-github-connect/enabling-server-statistics-for-your-enterprise)."
|
||||
|
||||
To preview the metrics available to download, see "[About {% data variables.product.prodname_server_statistics %}](/admin/monitoring-activity-in-your-enterprise/analyzing-how-your-team-works-with-server-statistics/about-server-statistics)."
|
||||
|
||||
To download these metrics, you must be an enterprise owner or organization owner on {% data variables.product.prodname_ghe_cloud %}.
|
||||
- If {% data variables.product.product_location %} is connected to an enterprise account on {% data variables.product.prodname_ghe_cloud %}, see "[Downloading metrics from your enterprise account](#downloading-metrics-from-your-enterprise-account)."
|
||||
- If {% data variables.product.product_location %} is connected to an organization on {% data variables.product.prodname_ghe_cloud %}, see "[Downloading metrics from your organization](#downloading-metrics-from-your-organization)."
|
||||
|
||||
To learn more about {% data variables.product.prodname_github_connect %}, see "[About {% data variables.product.prodname_github_connect %}](/admin/configuration/configuring-github-connect/about-github-connect)."
|
||||
|
||||
## Downloading metrics from your enterprise account
|
||||
|
||||
1. In the top-right corner of {% data variables.product.prodname_ghe_cloud %}, click your profile photo, then click **Your enterprises**.
|
||||
![Drop down menu with "Your enterprises" option](/assets/images/help/enterprises/enterprise-admin-account-settings.png)
|
||||
|
||||
2. Next to your desired enterprise account, click **Settings**.
|
||||
![Settings button next to Enterprise admin account](/assets/images/help/enterprises/enterprise-admin-account-settings-button.png)
|
||||
|
||||
3. On the left, click **GitHub Connect**.
|
||||
![GitHub Connect option under enterprise admin account](/assets/images//help/enterprises/enterprise-admin-github-connect.png)
|
||||
|
||||
{% data reusables.server-statistics.csv-download %}
|
||||
|
||||
## Downloading metrics from your organization
|
||||
|
||||
1. In the top-right corner of {% data variables.product.prodname_ghe_cloud %}, click your profile photo, then click **Your organizations**.
|
||||
![Drop down menu with "Your organizations" option](/assets/images/help/enterprises/github-enterprise-cloud-organizations.png)
|
||||
|
||||
2. In the list of organizations, next to the organization that's connected to {% data variables.product.product_location %}, click **Settings**.
|
||||
![Settings button next to {% data variables.product.prodname_ghe_cloud %} organization](/assets/images/help/enterprises/settings-for-ghec-org.png)
|
||||
|
||||
3. On the left, click **GitHub Connect**.
|
||||
![GitHub Connect option in an organization account settings left sidebar](/assets/images/help/enterprises/github-connect-option-for-ghec-org.png)
|
||||
|
||||
{% data reusables.server-statistics.csv-download %}
|
|
@ -0,0 +1,11 @@
|
|||
---
|
||||
title: Analyzing how your team works with Server Statistics
|
||||
shortTitle: Server Statistics
|
||||
intro: 'To analyze how your team works, understand the value you get from {% data variables.product.prodname_ghe_server %}, and help us improve our products, you can use {% data variables.product.prodname_server_statistics %} to review your usage data for {% data variables.product.prodname_ghe_server %} and share this aggregate data with {% data variables.product.company_short %}.'
|
||||
versions:
|
||||
feature: 'server-statistics'
|
||||
children:
|
||||
- /about-server-statistics
|
||||
- /exporting-server-statistics
|
||||
- /requesting-server-statistics-using-the-rest-api
|
||||
---
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
title: Requesting Server Statistics using the REST API
|
||||
shortTitle: Server Statistics and REST API
|
||||
intro: 'You can use your own tools to analyze your {% data variables.product.prodname_ghe_server %} usage over time by requesting the {% data variables.product.prodname_server_statistics %} metrics collected using the REST API.'
|
||||
versions:
|
||||
feature: 'server-statistics'
|
||||
redirect_from:
|
||||
- /early-access/github/analyze-how-your-team-works-with-server-statistics/requesting-server-statistics-using-the-rest-api
|
||||
---
|
||||
|
||||
{% data reusables.server-statistics.release-phase %}
|
||||
|
||||
You can request up to 365 days of metrics in a single {% data variables.product.prodname_server_statistics %} REST API request. This data, which includes aggregate metrics on repositories, issues, and pull requests, can help you anticipate the needs of your organization, understand how your team works, and show the value you get from {% data variables.product.prodname_ghe_server %}. For a list of the metrics collected, see "[{% data variables.product.prodname_server_statistics %} data collected](/admin/monitoring-activity-in-your-enterprise/analyzing-how-your-team-works-with-server-statistics/about-server-statistics#server-statistics-data-collected)."
|
||||
|
||||
Before you can use the {% data variables.product.prodname_server_statistics %} REST API, you must enable {% data variables.product.prodname_server_statistics %}. For more information, see "[Enabling {% data variables.product.prodname_server_statistics %} for your enterprise](/admin/configuration/configuring-github-connect/enabling-server-statistics-for-your-enterprise)."
|
||||
|
||||
For more information about using the REST API to request server statistics, see "[Get {% data variables.product.prodname_ghe_server %} statistics](/enterprise-cloud@latest/rest/enterprise-admin/admin-stats#get-github-enterprise-server-statistics)" in the {% data variables.product.prodname_ghe_cloud %} REST API documentation.
|
|
@ -12,5 +12,6 @@ topics:
|
|||
children:
|
||||
- /reviewing-audit-logs-for-your-enterprise
|
||||
- /exploring-user-activity
|
||||
- /analyzing-how-your-team-works-with-server-statistics
|
||||
shortTitle: Monitor activity
|
||||
---
|
||||
|
|
|
@ -1181,7 +1181,7 @@ Action | Description
|
|||
| `restrict_notification_delivery.disable` | Email notification restrictions for an organization or enterprise were disabled. For more information, see "[Restricting email notifications for your organization](/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/restricting-email-notifications-for-your-organization)" and "[Restricting email notifications for your enterprise](/admin/policies/enforcing-policies-for-your-enterprise/restricting-email-notifications-for-your-enterprise)."
|
||||
{%- endif %}
|
||||
|
||||
{%- ifversion ghec or ghes > 3.4 or ghae-issue-6271 %}
|
||||
{%- if custom-repository-roles %}
|
||||
### `role` category actions
|
||||
|
||||
| Action | Description
|
||||
|
|
|
@ -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 Docker, RubyGems, npm, Apache Maven, Gradle, or NuGet. 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 > 3.4 %}{% data variables.product.prodname_container_registry %}, {% endif %}Docker, and npm. Learn about other configuration requirements to support specific package ecosystems.'
|
||||
redirect_from:
|
||||
- /enterprise/admin/packages/configuring-packages-support-for-your-enterprise
|
||||
- /admin/packages/configuring-packages-support-for-your-enterprise
|
||||
|
@ -22,7 +22,10 @@ To prevent new packages from being uploaded, you can set an ecosystem you previo
|
|||
{% data reusables.enterprise_site_admin_settings.access-settings %}
|
||||
{% 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.1 %}
|
||||
1. Under "Ecosystem Toggles", for each package type, select **Enabled**, **Read-Only**, or **Disabled**.
|
||||
{%- ifversion ghes > 3.4 %}{% note -%}
|
||||
**Note**: Subdomain isolation must be enabled to toggle the {% data variables.product.prodname_container_registry %} options.
|
||||
{%- endnote %}{%- endif %}{%- ifversion ghes > 3.1 %}
|
||||
![Ecosystem toggles](/assets/images/enterprise/site-admin-settings/ecosystem-toggles.png){% else %}
|
||||
![Ecosystem toggles](/assets/images/enterprise/3.1/site-admin-settings/ecosystem-toggles.png){% endif %}
|
||||
{% data reusables.enterprise_management_console.save-settings %}
|
||||
|
|
|
@ -37,10 +37,10 @@ To enable {% data variables.product.prodname_registry %} and configure third-par
|
|||
|
||||
## Step 3: Specify the package ecosystems to support on your instance
|
||||
|
||||
Choose which package ecosystems you'd like to enable, disable, or set to read-only on {% data variables.product.product_location %}. Available options are Docker, RubyGems, npm, Apache Maven, Gradle, or NuGet. For more information, see "[Configuring package ecosystem support for your enterprise](/enterprise/admin/packages/configuring-package-ecosystem-support-for-your-enterprise)."
|
||||
Choose which package ecosystems you'd like to enable, disable, or set to read-only on {% data variables.product.product_location %}. Available options are {% ifversion ghes > 3.4 %}{% data variables.product.prodname_container_registry %}, {% endif %}Docker, RubyGems, npm, Apache Maven, Gradle, or NuGet. For more information, see "[Configuring package ecosystem support for your enterprise](/enterprise/admin/packages/configuring-package-ecosystem-support-for-your-enterprise)."
|
||||
|
||||
## Step 4: Ensure you have a TLS certificate for your package host URL, if needed
|
||||
|
||||
If subdomain isolation is enabled for {% data variables.product.product_location %}, you will need to create and upload a TLS certificate that allows the package host URL for each ecosystem you want to use, such as `npm.HOSTNAME`. Make sure each package host URL includes `https://`.
|
||||
If subdomain isolation is enabled for {% data variables.product.product_location %}, you will need to create and upload a TLS certificate that allows the package host URL for each ecosystem you want to use, such as `{% data reusables.package_registry.container-registry-hostname %}`. Make sure each package host URL includes `https://`.
|
||||
|
||||
You can create the certificate manually, or you can use _Let's Encrypt_. If you already use _Let's Encrypt_, you must request a new TLS certificate after enabling {% data variables.product.prodname_registry %}. For more information about package host URLs, see "[Enabling subdomain isolation](/enterprise/admin/configuration/enabling-subdomain-isolation)." For more information about uploading TLS certificates to {% data variables.product.product_name %}, see "[Configuring TLS](/enterprise/admin/configuration/configuring-tls)."
|
||||
|
|
|
@ -133,3 +133,22 @@ You can set the default permissions for the `GITHUB_TOKEN` in the settings for y
|
|||
1. Click **Save** to apply the settings.
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% if actions-cache-policy-apis %}
|
||||
|
||||
## Enforcing a policy for cache storage in your enterprise
|
||||
|
||||
{% data reusables.actions.cache-default-size %} {% data reusables.actions.cache-eviction-process %}
|
||||
|
||||
However, you can set an enterprise policy to customize both the default total cache size for each repository, as well as the maximum total cache size allowed for a repository. For example, you might want the default total cache size for each repository to be 5 GB, but also allow repository administrators to configure a total cache size up to 15 GB if necessary.
|
||||
|
||||
People with admin access to a repository can set a total cache size for their repository up to the maximum cache size allowed by the enterprise policy setting.
|
||||
|
||||
The policy settings for {% data variables.product.prodname_actions %} cache storage can currently only be modified using the REST API:
|
||||
|
||||
* To view the current enterprise policy settings, see "[Get GitHub Actions cache usage policy for an enterprise](/rest/actions/cache#get-github-actions-cache-usage-policy-for-an-enterprise)."
|
||||
* To change the enterprise policy settings, see "[Set GitHub Actions cache usage policy for an enterprise](/rest/actions/cache#get-github-actions-cache-usage-policy-for-an-enterprise)."
|
||||
|
||||
{% data reusables.actions.cache-no-org-policy %}
|
||||
|
||||
{% endif %}
|
||||
|
|
|
@ -22,23 +22,31 @@ shortTitle: Manage your organization roles
|
|||
|
||||
You can choose to join an organization owned by your enterprise as a member or as an organization owner, change your role within the organization, or leave the organization.
|
||||
|
||||
{% ifversion ghec %}
|
||||
{% warning %}
|
||||
|
||||
**Warning**: If an organization uses SCIM to provision users, joining the organization this way could have unintended consequences. For more information, see "[About SCIM for organizations](/organizations/managing-saml-single-sign-on-for-your-organization/about-scim-for-organizations)."
|
||||
|
||||
{% endwarning %}
|
||||
{% endif %}
|
||||
|
||||
## Managing your role with the enterprise settings
|
||||
|
||||
You can join an organization owned by your enterprise and manage your role within the organization, directly from the settings for your enterprise account.
|
||||
|
||||
{% ifversion ghec %}
|
||||
|
||||
If an organization enforces SAML single sign-on (SSO), you cannot use the enterprise settings to join the organization. Instead, you must join the organization using that organization's identity provider (IdP). Then, you can manage your role in your enterprise settings. For more information, see "[Joining an organization that enforces SAML SSO](#joining-an-organization-that-enforces-saml-sso)."
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% data reusables.enterprise-accounts.access-enterprise %}
|
||||
1. On the **Organizations** tab, to the right of the organization you want to manage your role in, select the {% octicon "gear" aria-label="The gear icon" %} dropdown menu and click the action you want to take.
|
||||
|
||||
![Screenshot of the dropdown menu for the gear icon for an organization](/assets/images/help/business-accounts/change-role-in-org.png)
|
||||
|
||||
{% ifversion ghec %}
|
||||
|
||||
## Joining an organization that enforces SAML SSO
|
||||
|
||||
If an organization enforces SAML SSO, you cannot use the enterprise settings to join the organization. Instead, you must join the organization using that organization's identity provider (IdP).
|
||||
|
@ -52,3 +60,5 @@ If an organization enforces SAML SSO, you cannot use the enterprise settings to
|
|||
`https://github.com/orgs/ORGANIZATION/sso`
|
||||
|
||||
After you've joined the organization, you can use the enterprise settings to manage your role in the organization, such as becoming an organization owner. For more information, see "[Managing your role with the enterprise settings](#managing-your-role-with-the-enterprise-settings)."
|
||||
|
||||
{% endif %}
|
|
@ -48,8 +48,11 @@ Repository administrators can enforce required commit signing on a branch to blo
|
|||
|
||||
{% data reusables.identity-and-permissions.verification-status-check %}
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
{% data variables.product.product_name %} will automatically use GPG to sign commits you make using the {% data variables.product.product_name %} web interface. Commits signed by {% data variables.product.product_name %} will have a verified status on {% data variables.product.product_name %}. 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`. You can optionally choose to have {% data variables.product.product_name %} sign commits you make in {% data variables.product.prodname_codespaces %}. For more information about enabling GPG verification for your codespaces, see "[Managing GPG verification for {% data variables.product.prodname_codespaces %}](/github/developing-online-with-codespaces/managing-gpg-verification-for-codespaces)."
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
{% 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 "[Configuring web commit signing](/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`.
|
||||
|
||||
You can optionally choose to have {% data variables.product.prodname_dotcom %} sign commits you make in {% data variables.product.prodname_codespaces %}. For more information about enabling GPG verification for your codespaces, see "[Managing GPG verification for {% data variables.product.prodname_codespaces %}](/github/developing-online-with-codespaces/managing-gpg-verification-for-codespaces)."{% endif %}
|
||||
{% endif %}
|
||||
|
||||
## GPG commit signature verification
|
||||
|
|
|
@ -18,7 +18,7 @@ shortTitle: Sync license usage
|
|||
|
||||
To ensure that you see up-to-date license details on {% data variables.product.prodname_dotcom_the_website %}, you can sync license usage between the environments automatically, using {% data variables.product.prodname_github_connect %}. For more information about {% data variables.product.prodname_github_connect %}, see "[About {% data variables.product.prodname_github_connect %}]({% ifversion ghec %}/enterprise-server@latest{% endif %}/admin/configuration/configuring-github-connect/about-github-connect){% ifversion ghec %}" in the {% data variables.product.prodname_ghe_server %} documentation.{% elsif ghes %}."{% endif %}
|
||||
|
||||
If you don't want to enable {% data variables.product.prodname_github_connect %}, you can manually sync license usage by uploading a file from {% data variables.product.prodname_ghe_server %} to {% data variables.product.prodname_dotcom_the_website %}.
|
||||
If you don't want to enable {% data variables.product.prodname_github_connect %}, you can manually sync license usage by uploading a file from {% data variables.product.prodname_ghe_server %} to {% data variables.product.prodname_dotcom_the_website %}.
|
||||
|
||||
{% data reusables.enterprise-licensing.view-consumed-licenses %}
|
||||
|
||||
|
@ -26,9 +26,23 @@ If you don't want to enable {% data variables.product.prodname_github_connect %}
|
|||
|
||||
## Automatically syncing license usage
|
||||
|
||||
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 %}. 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 %}
|
||||
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 %}
|
||||
|
||||
## Manually syncing license usage
|
||||
{% ifversion ghec or ghes > 3.4 %}
|
||||
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
|
||||
|
||||
1. Sign in to your {% data variables.product.prodname_ghe_server %} instance.
|
||||
{% data reusables.enterprise-accounts.access-enterprise %}
|
||||
{% data reusables.enterprise-accounts.settings-tab %}
|
||||
{% data reusables.enterprise-accounts.license-tab %}
|
||||
1. Under "License sync", click {% octicon "sync" aria-label="The Sync icon" %} **Sync now**.
|
||||
![Screenshot of "Sync now" button in license sync section](/assets/images/help/enterprises/license-sync-now-ghes.png)
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Manually uploading GitHub Enterprise Server license usage
|
||||
|
||||
You can download a JSON file from {% data variables.product.prodname_ghe_server %} and upload the file to {% data variables.product.prodname_ghe_cloud %} to manually sync user license usage between the two deployments.
|
||||
|
||||
|
@ -39,8 +53,6 @@ You can download a JSON file from {% data variables.product.prodname_ghe_server
|
|||
![Export license usage link](/assets/images/enterprise/business-accounts/export-license-usage-link.png)
|
||||
{% data reusables.enterprise-accounts.access-enterprise-on-dotcom %}
|
||||
{% data reusables.enterprise-accounts.settings-tab %}
|
||||
8. In the left sidebar, click **Enterprise licensing**.
|
||||
!["Enterprise licensing" tab in the enterprise account settings sidebar](/assets/images/help/enterprises/enterprise-licensing-tab.png)
|
||||
{% data reusables.enterprise-accounts.license-tab %}
|
||||
10. Under "Enterprise Server Instances", click **Add server usage**.
|
||||
![Upload GitHub Enterprise Servers usage link](/assets/images/help/business-accounts/upload-ghe-server-usage-link.png)
|
||||
|
|
|
@ -24,7 +24,7 @@ If there's a particular topic that interests you, visit `github.com/topics/<topi
|
|||
|
||||
If you've been active on {% data variables.product.product_location %}, you can find personalized recommendations for projects and good first issues based on your past contributions, stars, and other activities in [Explore](https://github.com/explore). You can also sign up for the Explore newsletter to receive emails about opportunities to contribute to {% data variables.product.product_name %} based on your interests. To sign up, see [Explore email newsletter](https://github.com/explore/subscribe).
|
||||
|
||||
Keep up with recent activity from repositories you watch and people{% if for-you-feed %}, and organizations{% endif %} you follow with your personal dashboard. For more information, see "[About your personal dashboard](/articles/about-your-personal-dashboard)."
|
||||
Keep up with recent activity from repositories you watch, as well as people and organizations you follow, with your personal dashboard. For more information, see "[About your personal dashboard](/articles/about-your-personal-dashboard)."
|
||||
|
||||
{% data reusables.support.ask-and-answer-forum %}
|
||||
|
||||
|
|
|
@ -17,7 +17,7 @@ topics:
|
|||
|
||||
When you follow organizations, you'll see their public activity on your personal dashboard. For more information, see "[About your personal dashboard](/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/about-your-personal-dashboard#staying-updated-with-activity-from-the-community)."
|
||||
|
||||
You can unfollow an organization if you do not wish to see their public activity on {% data variables.product.product_name %}.
|
||||
You can unfollow an organization if you do not wish to see their {% ifversion fpt or ghec %}public{% endif %} activity on {% data variables.product.product_name %}.
|
||||
|
||||
## Following an organization on {% data variables.product.product_name %}
|
||||
|
||||
|
|
|
@ -77,7 +77,7 @@ To search for specific events, use the `action` qualifier in your query. Actions
|
|||
| [`repository_secret_scanning_custom_pattern`](#respository_secret_scanning_custom_pattern-category-actions) | Contains repository-level activities related to secret scanning custom patterns. For more information, see "[Defining custom patterns for secret scanning](/code-security/secret-scanning/defining-custom-patterns-for-secret-scanning)." {% endif %}{% if secret-scanning-audit-log-custom-patterns %}
|
||||
| [`repository_secret_scanning_push_protection`](#respository_secret_scanning_push_protection) | Contains repository-level activities related to secret scanning custom patterns. For more information, see "[Protecting pushes with secert scanning](/code-security/secret-scanning/protecting-pushes-with-secret-scanning)." {% endif %}{% ifversion fpt or ghes or ghae-issue-4864 or ghec %}
|
||||
| [`repository_vulnerability_alert`](#repository_vulnerability_alert-category-actions) | Contains all activities related to [{% data variables.product.prodname_dependabot_alerts %} for vulnerable dependencies](/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies).{% endif %}{% ifversion fpt or ghec %}
|
||||
| [`repository_vulnerability_alerts`](#repository_vulnerability_alerts-category-actions) | Contains repository-level configuration activities for {% data variables.product.prodname_dependabot_alerts %}.{% endif %}{% ifversion ghec %}
|
||||
| [`repository_vulnerability_alerts`](#repository_vulnerability_alerts-category-actions) | Contains repository-level configuration activities for {% data variables.product.prodname_dependabot_alerts %}.{% endif %}{% if custom-repository-roles %}
|
||||
| [`role`](#role-category-actions) | Contains all activities related to [custom repository roles](/organizations/managing-peoples-access-to-your-organization-with-roles/managing-custom-repository-roles-for-an-organization).{% endif %}{% ifversion ghes or ghae or ghec %}
|
||||
| [`secret_scanning`](#secret_scanning-category-actions) | Contains organization-level configuration activities for secret scanning in existing repositories. For more information, see "[About secret scanning](/github/administering-a-repository/about-secret-scanning)."
|
||||
| [`secret_scanning_new_repos`](#secret_scanning_new_repos-category-actions) | Contains organization-level configuration activities for secret scanning for new repositories created in the organization. {% endif %}{% ifversion fpt or ghec %}
|
||||
|
@ -725,7 +725,7 @@ For more information, see "[Managing the publication of {% data variables.produc
|
|||
| `disable` | Triggered when a repository owner or person with admin access to the repository disables {% data variables.product.prodname_dependabot_alerts %}.
|
||||
| `enable` | Triggered when a repository owner or person with admin access to the repository enables {% data variables.product.prodname_dependabot_alerts %}.
|
||||
|
||||
{% endif %}{% ifversion ghec %}
|
||||
{% endif %}{% if custom-repository-roles %}
|
||||
### `role` category actions
|
||||
| Action | Description
|
||||
|------------------|-------------------
|
||||
|
|
|
@ -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 "[Managing custom repository roles for an organization](/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 %}
|
||||
{% elsif ghec or ghes > 3.4 or ghae-issue-6271 %}
|
||||
You can create custom repository roles. For more information, see "[Managing custom repository roles for an organization](/organizations/managing-peoples-access-to-your-organization-with-roles/managing-custom-repository-roles-for-an-organization)."
|
||||
{% endif %}
|
||||
|
||||
|
|
|
@ -23,7 +23,7 @@ You can set base permissions that apply to all members of an organization when a
|
|||
|
||||
If someone with admin access to an organization's repository grants a member a higher level of access for the repository, the higher level of access overrides the base permission.
|
||||
|
||||
{% ifversion ghec %}
|
||||
{% if custom-repository-roles %}
|
||||
If you've created a custom repository role with an inherited role that is lower access than your organization's base permissions, any members assigned to that role will default to the organization's base permissions rather than the inherited role. For more information, see "[Managing custom repository roles for an organization](/organizations/managing-peoples-access-to-your-organization-with-roles/managing-custom-repository-roles-for-an-organization)."
|
||||
{% endif %}
|
||||
|
||||
|
|
|
@ -3,7 +3,7 @@ title: Managing custom repository roles for an organization
|
|||
intro: You can more granularly control access to your organization's repositories by creating custom repository roles.
|
||||
permissions: Organization owners can manage custom repository roles.
|
||||
versions:
|
||||
ghec: '*'
|
||||
feature: 'custom-repository-roles'
|
||||
topics:
|
||||
- Organizations
|
||||
- Teams
|
||||
|
@ -49,6 +49,7 @@ After choosing an inherited role, you can select additional permissions for your
|
|||
|
||||
You can only choose an additional permission if it's not already included in the inherited role. For example, if the inherited role offers **Write** access to a repository, then the "Close a pull request" permission will already be included in the inherited role.
|
||||
|
||||
{% ifversion ghec %}
|
||||
### Discussions
|
||||
|
||||
- **Create a discussion category**: Ability to create a new discussion category. For more information, see "[Creating a new discussion category](/discussions/managing-discussions-for-your-community/managing-categories-for-discussions#creating-a-category)".
|
||||
|
@ -57,6 +58,7 @@ You can only choose an additional permission if it's not already included in the
|
|||
- **Mark or unmark discussion answers**: Ability to mark answers to a discussion, if the category for the discussion accepts answers. For more information, see "[Mark or unmark comments in a discussion as the answer](/discussions/managing-discussions-for-your-community/moderating-discussions#marking-a-comment-as-an-answer)".
|
||||
- **Hide or unhide discussion comments**: Ability to hide and unhide comments in a discussion. For more information, see "[Moderating discussions](/communities/moderating-comments-and-conversations/managing-disruptive-comments#hiding-a-comment)."
|
||||
- **Convert issues to discussions**: Ability to convert an issue into a discussion. For more information, see "[Converting issues to discussions](/discussions/managing-discussions-for-your-community/moderating-discussions#converting-an-issue-to-a-discussion)."
|
||||
{% endif %}
|
||||
|
||||
### Issue and Pull Requests
|
||||
|
||||
|
@ -86,7 +88,9 @@ You can only choose an additional permission if it's not already included in the
|
|||
- **Manage webhooks**: Add webhooks to the repository.
|
||||
- **Manage deploy keys**: Add deploy keys to the repository.
|
||||
- **Edit repository metadata**: Update the repository description as well as the repository topics.
|
||||
{%- ifversion ghec %}
|
||||
- **Set interaction limits**: Temporarily restrict certain users from commenting, opening issues, or creating pull requests in your public repository to enforce a period of limited activity. For more information, see "[Limiting interactions in your repository](/communities/moderating-comments-and-conversations/limiting-interactions-in-your-repository)."
|
||||
{%- endif %}
|
||||
- **Set the social preview**: Add an identifying image to your repository that appears on social media platforms when your repository is linked. For more information, see "[Customizing your repository's social media preview](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/customizing-your-repositorys-social-media-preview)."
|
||||
- **Push commits to protected branches**: Push to a branch that is marked as a protected branch.
|
||||
- **Create protected tags**: Create tags that match a tag protection rule. For more information, see "[Configuring tag protection rules](/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/configuring-tag-protection-rules)."
|
||||
|
|
|
@ -12,11 +12,11 @@ featuredLinks:
|
|||
- /packages/learn-github-packages/installing-a-package
|
||||
popular:
|
||||
- /packages/working-with-a-github-packages-registry/working-with-the-npm-registry
|
||||
- '{% ifversion fpt or ghec%}/packages/working-with-a-github-packages-registry/working-with-the-container-registry{% else %}/packages/working-with-a-github-packages-registry/working-with-the-docker-registry{% endif %}'
|
||||
- '{% ifversion fpt or ghec or ghes > 3.4 %}/packages/working-with-a-github-packages-registry/working-with-the-container-registry{% else %}/packages/working-with-a-github-packages-registry/working-with-the-docker-registry{% endif %}'
|
||||
- /packages/learn-github-packages
|
||||
- /packages/working-with-a-github-packages-registry/working-with-the-apache-maven-registry
|
||||
guideCards:
|
||||
- '{% ifversion fpt or ghec %}/packages/working-with-a-github-packages-registry/working-with-the-container-registry{% else %}/packages/working-with-a-github-packages-registry/working-with-the-docker-registry{% endif %}'
|
||||
- '{% ifversion fpt or ghec or ghes > 3.4 %}/packages/working-with-a-github-packages-registry/working-with-the-container-registry{% else %}/packages/working-with-a-github-packages-registry/working-with-the-docker-registry{% endif %}'
|
||||
- /packages/working-with-a-github-packages-registry/working-with-the-rubygems-registry
|
||||
changelog:
|
||||
label: packages
|
||||
|
|
|
@ -8,8 +8,10 @@ redirect_from:
|
|||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '*'
|
||||
shortTitle: Access control & visibility
|
||||
---
|
||||
{% data reusables.package_registry.container-registry-ghes-beta %}
|
||||
|
||||
Packages with granular permissions are scoped to a personal user or organization account. You can change the access control and visibility of a package separately from the repository that it is connected (or linked) to.
|
||||
|
||||
|
@ -27,7 +29,7 @@ If you have admin permissions to a container image that's owned by a personal ac
|
|||
|
||||
If your package is private or internal and owned by an organization, then you can only give access to other organization members or teams.
|
||||
|
||||
{% data reusables.package_registry.package-settings-from-user-level %}
|
||||
{% data reusables.package_registry.package-settings-option %}
|
||||
1. On the package settings page, click **Invite teams or people** and enter the name, username, or email of the person you want to give access. Teams cannot be given access to a container image owned by a personal account.
|
||||
![Container access invite button](/assets/images/help/package-registry/container-access-invite.png)
|
||||
1. Next to the username or team name, use the "Role" drop-down menu to select a desired permission level.
|
||||
|
@ -42,6 +44,7 @@ If you have admin permissions to an organization-owned container image, you can
|
|||
If your package is private or internal and owned by an organization, then you can only give access to other organization members or teams.
|
||||
|
||||
{% data reusables.package_registry.package-settings-from-org-level %}
|
||||
{% data reusables.package_registry.package-settings-option %}
|
||||
1. On the package settings page, click **Invite teams or people** and enter the name, username, or email of the person you want to give access. You can also enter a team name from the organization to give all team members access.
|
||||
![Container access invite button](/assets/images/help/package-registry/container-access-invite.png)
|
||||
1. Next to the username or team name, use the "Role" drop-down menu to select a desired permission level.
|
||||
|
@ -58,6 +61,7 @@ If you inherit the access permissions of the repository where your package's wor
|
|||
Once a repository is synced, you can't access the package's granular access settings. To customize the package's permissions through the granular package access settings, you must remove the synced repository first.
|
||||
|
||||
{% data reusables.package_registry.package-settings-from-org-level %}
|
||||
{% data reusables.package_registry.package-settings-option %}
|
||||
2. Under "Repository source", select **Inherit access from repository (recommended)**.
|
||||
![Inherit repo access checkbox](/assets/images/help/package-registry/inherit-repo-access-for-package.png)
|
||||
|
||||
|
@ -75,7 +79,7 @@ The specified repository does not need to be the repository where the source cod
|
|||
|
||||
### {% data variables.product.prodname_actions %} access for user-account-owned container images
|
||||
|
||||
{% data reusables.package_registry.package-settings-from-user-level %}
|
||||
{% data reusables.package_registry.package-settings-option %}
|
||||
1. In the left sidebar, click **Actions access**.
|
||||
!["Actions access" option in left menu](/assets/images/help/package-registry/organization-repo-access-for-a-package.png)
|
||||
2. To ensure your workflow has access to your container package, you must add the repository where the workflow is stored. Click **Add repository** and search for the repository you want to add.
|
||||
|
@ -88,6 +92,7 @@ To further customize access to your container image, see "[Configuring access to
|
|||
### {% data variables.product.prodname_actions %} access for organization-owned container images
|
||||
|
||||
{% data reusables.package_registry.package-settings-from-org-level %}
|
||||
{% data reusables.package_registry.package-settings-option %}
|
||||
1. In the left sidebar, click **Actions access**.
|
||||
!["Actions access" option in left menu](/assets/images/help/package-registry/organization-repo-access-for-a-package.png)
|
||||
2. Click **Add repository** and search for the repository you want to add.
|
||||
|
@ -97,6 +102,7 @@ To further customize access to your container image, see "[Configuring access to
|
|||
|
||||
To further customize access to your container image, see "[Configuring access to container images for an organization](#configuring-access-to-container-images-for-an-organization)."
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
## Ensuring {% data variables.product.prodname_codespaces %} access to your package
|
||||
|
||||
By default, a codespace can seamlessly access certain packages in the {% data variables.product.prodname_dotcom %} Container Registry, such as those published in the same repository with the **Inherit access** option selected. For more information on which access is automatically configured, see "[Accessing images stored in {% data variables.product.prodname_dotcom %} Container Registry](/codespaces/codespaces-reference/allowing-your-codespace-to-access-a-private-image-registry#accessing-images-stored-in-github-container-registry)."
|
||||
|
@ -125,13 +131,14 @@ Once you've selected the package you're interested in sharing with codespaces in
|
|||
|
||||
!["Remove repository" button](/assets/images/help/package-registry/manage-codespaces-access-item.png)
|
||||
|
||||
{% endif %}
|
||||
## Configuring visibility of container images for your personal account
|
||||
|
||||
When you first publish a package, the default visibility is private and only you can see the package. You can modify a private or public container image's access by changing the access settings.
|
||||
|
||||
A public package can be accessed anonymously without authentication. Once you make your package public, you cannot make your package private again.
|
||||
|
||||
{% data reusables.package_registry.package-settings-from-user-level %}
|
||||
{% data reusables.package_registry.package-settings-option %}
|
||||
5. Under "Danger Zone", choose a visibility setting:
|
||||
- To make the container image visible to anyone, click **Make public**.
|
||||
{% warning %}
|
||||
|
@ -162,6 +169,7 @@ When you first publish a package, the default visibility is private and only you
|
|||
A public package can be accessed anonymously without authentication. Once you make your package public, you cannot make your package private again.
|
||||
|
||||
{% data reusables.package_registry.package-settings-from-org-level %}
|
||||
{% data reusables.package_registry.package-settings-option %}
|
||||
5. Under "Danger Zone", choose a visibility setting:
|
||||
- To make the container image visible to anyone, click **Make public**.
|
||||
{% warning %}
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Connecting a repository to a package
|
||||
intro: 'You can connect a repository to a container image on {% data variables.product.prodname_dotcom %}.'
|
||||
intro: 'You can connect a repository to a container image on {% data variables.product.product_location %}.'
|
||||
product: '{% data reusables.gated-features.packages %}'
|
||||
redirect_from:
|
||||
- /packages/managing-container-images-with-github-container-registry/connecting-a-repository-to-a-container-image
|
||||
|
@ -8,6 +8,7 @@ redirect_from:
|
|||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '*'
|
||||
shortTitle: Connect a repository
|
||||
---
|
||||
|
||||
|
@ -25,16 +26,21 @@ By connecting a repository to a package, the package landing page will show info
|
|||
|
||||
{% data reusables.package_registry.repository_connection_steps %}
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
## Connecting a repository to a container image using the command line
|
||||
|
||||
1. In your Dockerfile, add this line, replacing `OWNER` and `REPO` with your details:
|
||||
{% ifversion ghes > 3.4 %}
|
||||
{% data reusables.package_registry.container-registry-ghes-beta %}
|
||||
{% endif %}
|
||||
|
||||
1. In your Dockerfile, add this line, replacing {% ifversion ghes %}`HOSTNAME`, {% endif %}`OWNER` and `REPO` with your details:
|
||||
|
||||
```shell
|
||||
LABEL org.opencontainers.image.source=https://github.com/<em>OWNER</em>/<em>REPO</em>
|
||||
LABEL org.opencontainers.image.source=https://{% ifversion fpt or ghec %}github.com{% else %}<em>HOSTNAME</em>{% endif %}/<em>OWNER</em>/<em>REPO</em>
|
||||
```
|
||||
For example, if you're the user `monalisa` and own `my-repo`, you would add this line to your Dockerfile:
|
||||
For example, if you're the user `monalisa` and own `my-repo`, and {% data variables.product.product_location %} hostname is `github.companyname.com`, you would add this line to your Dockerfile:
|
||||
```shell
|
||||
LABEL org.opencontainers.image.source=https://github.com/monalisa/my-repo
|
||||
LABEL org.opencontainers.image.source=https://{% ifversion fpt or ghec %}github.com{% else %}{% data reusables.package_registry.container-registry-example-hostname %}{% endif %}/monalisa/my-repo
|
||||
```
|
||||
For more information, see "[LABEL](https://docs.docker.com/engine/reference/builder/#label)" in the official Docker documentation and "[Pre-defined Annotation Keys](https://github.com/opencontainers/image-spec/blob/master/annotations.md#pre-defined-annotation-keys)" in the `opencontainers/image-spec` repository.
|
||||
|
||||
|
@ -46,33 +52,34 @@ By connecting a repository to a package, the package landing page will show info
|
|||
3. Optionally, review details for the Docker image you want to tag.
|
||||
```shell
|
||||
$ docker images
|
||||
> REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||
> ghcr.io/my-org/hello_docker latest 38f737a91f39 47 hours ago 91.7MB
|
||||
> ghcr.io/my-username/hello_docker latest 38f737a91f39 47 hours ago 91.7MB
|
||||
> hello-world latest fce289e99eb9 16 months ago 1.84kB
|
||||
> REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||
> {% data reusables.package_registry.container-registry-example-hostname %}/my-org/hello_docker latest 38f737a91f39 47 hours ago 91.7MB
|
||||
> {% data reusables.package_registry.container-registry-example-hostname %}/my-username/hello_docker latest 38f737a91f39 47 hours ago 91.7MB
|
||||
> hello-world latest fce289e99eb9 16 months ago 1.84kB
|
||||
```
|
||||
|
||||
4. Tag your Docker image with your desired image name and hosting destination.
|
||||
```shell
|
||||
$ docker tag IMAGE_NAME ghcr.io/OWNER/NEW_IMAGE_NAME:TAG
|
||||
$ docker tag IMAGE_NAME {% data reusables.package_registry.container-registry-hostname %}/OWNER/NEW_IMAGE_NAME:TAG
|
||||
```
|
||||
For example:
|
||||
```shell
|
||||
$ docker tag 38f737a91f39 ghcr.io/monalisa/hello_docker:latest
|
||||
$ docker tag 38f737a91f39 {% data reusables.package_registry.container-registry-example-hostname %}/monalisa/hello_docker:latest
|
||||
```
|
||||
|
||||
5. If you haven't already, authenticate to the {% data variables.product.prodname_container_registry %}. For more information, see "[Authenticating to the {% data variables.product.prodname_container_registry %}](/packages/managing-container-images-with-github-container-registry/pushing-and-pulling-docker-images#authenticating-to-the-container-registry)."
|
||||
{% raw %}
|
||||
```shell
|
||||
$ echo $CR_PAT | docker login ghcr.io -u USERNAME --password-stdin
|
||||
$ echo $CR_PAT | docker login {% endraw %}{% data reusables.package_registry.container-registry-hostname %}{% raw %} -u USERNAME --password-stdin
|
||||
> Login Succeeded
|
||||
```
|
||||
{% endraw %}
|
||||
6. Push your container image to the {% data variables.product.prodname_container_registry %}.
|
||||
```shell
|
||||
$ docker push ghcr.io/OWNER/IMAGE-NAME:TAG
|
||||
$ docker push {% data reusables.package_registry.container-registry-hostname %}/OWNER/IMAGE-NAME:TAG
|
||||
```
|
||||
For example:
|
||||
```shell
|
||||
$ docker push ghcr.io/monalisa/hello_docker:latest
|
||||
$ docker push {% data reusables.package_registry.container-registry-example-hostname %}/monalisa/hello_docker:latest
|
||||
```
|
||||
{% endif %}
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Working with the Container registry
|
||||
intro: 'You can store and manage Docker and OCI images in the {% data variables.product.prodname_container_registry %}, which uses the package namespace `https://ghcr.io`.'
|
||||
intro: 'You can store and manage Docker and OCI images in the {% data variables.product.prodname_container_registry %}, which uses the package namespace `https://{% data reusables.package_registry.container-registry-hostname %}`.'
|
||||
product: '{% data reusables.gated-features.packages %}'
|
||||
redirect_from:
|
||||
- /packages/managing-container-images-with-github-container-registry/pushing-and-pulling-docker-images
|
||||
|
@ -15,9 +15,22 @@ redirect_from:
|
|||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '>= 3.5'
|
||||
shortTitle: Container registry
|
||||
---
|
||||
{% ifversion ghes > 3.4 %}
|
||||
{% note %}
|
||||
|
||||
**Note**: {% data variables.product.prodname_container_registry %} is currently in beta for {% data variables.product.product_name %} and subject to change.
|
||||
|
||||
{% endnote %}
|
||||
{% endif %}
|
||||
|
||||
{% ifversion ghes > 3.4 %}
|
||||
## Prerequisites
|
||||
|
||||
To configure and use the {% data variables.product.prodname_container_registry %} on {% data variables.product.prodname_ghe_server %}, your site administrator must first enable {% data variables.product.prodname_registry %} **and** subdomain isolation. For more information, see "[Getting started with GitHub Packages for your enterprise](/admin/packages/getting-started-with-github-packages-for-your-enterprise)" and "[Enabling subdomain isolation](/admin/configuration/configuring-network-settings/enabling-subdomain-isolation)."
|
||||
{% endif %}
|
||||
## About {% data variables.product.prodname_container_registry %} support
|
||||
|
||||
The {% data variables.product.prodname_container_registry %} currently supports the following container image formats:
|
||||
|
@ -31,18 +44,20 @@ When installing or publishing a Docker image, the {% data variables.product.prod
|
|||
|
||||
{% data reusables.package_registry.authenticate_with_pat_for_container_registry %}
|
||||
|
||||
{% ifversion ghes %}Ensure that you replace `HOSTNAME` with {% data variables.product.product_location_enterprise %} hostname or IP address in the examples below.{% endif %}
|
||||
|
||||
{% data reusables.package_registry.authenticate-to-container-registry-steps %}
|
||||
|
||||
## Pushing container images
|
||||
|
||||
This example pushes the latest version of `IMAGE-NAME`.
|
||||
```shell
|
||||
$ docker push ghcr.io/OWNER/IMAGE_NAME:latest
|
||||
$ docker push {% data reusables.package_registry.container-registry-hostname %}/OWNER/IMAGE_NAME:latest
|
||||
```
|
||||
|
||||
This example pushes the `2.5` version of the image.
|
||||
```shell
|
||||
$ docker push ghcr.io/OWNER/IMAGE-NAME:2.5
|
||||
$ docker push {% data reusables.package_registry.container-registry-hostname %}/OWNER/IMAGE-NAME:2.5
|
||||
```
|
||||
|
||||
When you first publish a package, the default visibility is private. To change the visibility or set access permissions, see "[Configuring a package's access control and visibility](/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility)."
|
||||
|
@ -55,46 +70,46 @@ To ensure you're always using the same image, you can specify the exact containe
|
|||
|
||||
1. To find the digest SHA value, use `docker inspect` or `docker pull` and copy the SHA value after `Digest:`
|
||||
```shell
|
||||
$ docker inspect ghcr.io/OWNER/IMAGE_NAME
|
||||
$ docker inspect {% data reusables.package_registry.container-registry-hostname %}/OWNER/IMAGE_NAME
|
||||
```
|
||||
2. Remove image locally as needed.
|
||||
```shell
|
||||
$ docker rmi ghcr.io/OWNER/IMAGE_NAME:latest
|
||||
$ docker rmi {% data reusables.package_registry.container-registry-hostname %}/OWNER/IMAGE_NAME:latest
|
||||
```
|
||||
|
||||
3. Pull the container image with `@YOUR_SHA_VALUE` after the image name.
|
||||
```shell
|
||||
$ docker pull ghcr.io/OWNER/IMAGE_NAME@sha256:82jf9a84u29hiasldj289498uhois8498hjs29hkuhs
|
||||
$ docker pull {% data reusables.package_registry.container-registry-hostname %}/OWNER/IMAGE_NAME@sha256:82jf9a84u29hiasldj289498uhois8498hjs29hkuhs
|
||||
```
|
||||
|
||||
### Pull by name
|
||||
|
||||
```shell
|
||||
$ docker pull ghcr.io/OWNER/IMAGE_NAME
|
||||
$ docker pull {% data reusables.package_registry.container-registry-hostname %}/OWNER/IMAGE_NAME
|
||||
```
|
||||
|
||||
### Pull by name and version
|
||||
|
||||
Docker CLI example showing an image pulled by its name and the `1.14.1` version tag:
|
||||
```shell
|
||||
$ docker pull ghcr.io/OWNER/IMAGE_NAME:1.14.1
|
||||
$ docker pull {% data reusables.package_registry.container-registry-hostname %}/OWNER/IMAGE_NAME:1.14.1
|
||||
> 5e35bd43cf78: Pull complete
|
||||
> 0c48c2209aab: Pull complete
|
||||
> fd45dd1aad5a: Pull complete
|
||||
> db6eb50c2d36: Pull complete
|
||||
> Digest: sha256:ae3b135f133155b3824d8b1f62959ff8a72e9cf9e884d88db7895d8544010d8e
|
||||
> Status: Downloaded newer image for ghcr.io/orgname/image-name/release:1.14.1
|
||||
> ghcr.io/orgname/image-name/release:1.14.1
|
||||
> Status: Downloaded newer image for {% data reusables.package_registry.container-registry-hostname %}/orgname/image-name/release:1.14.1
|
||||
> {% data reusables.package_registry.container-registry-hostname %}/orgname/image-name/release:1.14.1
|
||||
```
|
||||
|
||||
### Pull by name and latest version
|
||||
|
||||
```shell
|
||||
$ docker pull ghcr.io/OWNER/IMAGE_NAME:latest
|
||||
$ docker pull {% data reusables.package_registry.container-registry-hostname %}/OWNER/IMAGE_NAME:latest
|
||||
> latest: Pulling from user/image-name
|
||||
> Digest: sha256:b3d3e366b55f9a54599220198b3db5da8f53592acbbb7dc7e4e9878762fc5344
|
||||
> Status: Downloaded newer image for ghcr.io/user/image-name:latest
|
||||
> ghcr.io/user/image-name:latest
|
||||
> Status: Downloaded newer image for {% data reusables.package_registry.container-registry-hostname %}/user/image-name:latest
|
||||
> {% data reusables.package_registry.container-registry-hostname %}/user/image-name:latest
|
||||
```
|
||||
|
||||
## Building container images
|
||||
|
@ -110,12 +125,12 @@ This example builds the `hello_docker` image:
|
|||
```shell
|
||||
$ docker images
|
||||
> REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||
> ghcr.io/my-org/hello_docker latest 38f737a91f39 47 hours ago 91.7MB
|
||||
> ghcr.io/my-username/hello_docker latest 38f737a91f39 47 hours ago 91.7MB
|
||||
> {% data reusables.package_registry.container-registry-hostname %}/my-org/hello_docker latest 38f737a91f39 47 hours ago 91.7MB
|
||||
> {% data reusables.package_registry.container-registry-hostname %}/my-username/hello_docker latest 38f737a91f39 47 hours ago 91.7MB
|
||||
> hello-world latest fce289e99eb9 16 months ago 1.84kB
|
||||
```
|
||||
|
||||
2. Tag your Docker image using the image ID and your desired image name and hosting destination.
|
||||
```shell
|
||||
$ docker tag 38f737a91f39 ghcr.io/OWNER/NEW_IMAGE_NAME:latest
|
||||
$ docker tag 38f737a91f39 {% data reusables.package_registry.container-registry-hostname %}/OWNER/NEW_IMAGE_NAME:latest
|
||||
```
|
||||
|
|
|
@ -28,7 +28,7 @@ topics:
|
|||
|
||||
{% endwarning %}
|
||||
|
||||
Some deleted repositories can be restored within 90 days of deletion. {% ifversion ghes or ghae %}Your site administrator may be able to restore a deleted repository for you. For more information, see "[Restoring a deleted repository](/admin/user-management/managing-repositories-in-your-enterprise/restoring-a-deleted-repository)." {% else %}For more information, see "[Restoring a deleted repository](/articles/restoring-a-deleted-repository)."{% endif %}
|
||||
Some deleted repositories can be restored within {% ifversion fpt or ghec or ghes > 3.4 %}30{% else %}90{% endif%} days of deletion. {% ifversion ghes or ghae %}Your site administrator may be able to restore a deleted repository for you. For more information, see "[Restoring a deleted repository](/admin/user-management/managing-repositories-in-your-enterprise/restoring-a-deleted-repository)." {% else %}For more information, see "[Restoring a deleted repository](/articles/restoring-a-deleted-repository)."{% endif %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
|
|
|
@ -19,7 +19,7 @@ Anyone can restore deleted repositories that were owned by their own personal ac
|
|||
|
||||
## About repository restoration
|
||||
|
||||
A deleted repository can be restored within 90 days, unless the repository was part of a fork network that is not currently empty. A fork network consists of a parent repository, the repository's forks, and forks of the repository's forks. If your repository was part of a fork network, it cannot be restored unless every other repository in the network is deleted or has been detached from the network. For more information about forks, see "[About forks](/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks)."
|
||||
A deleted repository can be restored within {% ifversion fpt or ghec or ghes > 3.4 %}30{% else %}90{% endif %} days, unless the repository was part of a fork network that is not currently empty. A fork network consists of a parent repository, the repository's forks, and forks of the repository's forks. If your repository was part of a fork network, it cannot be restored unless every other repository in the network is deleted or has been detached from the network. For more information about forks, see "[About forks](/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks)."
|
||||
|
||||
If you want to restore a repository that was part of a fork network that is not currently empty, you can contact {% data variables.contact.contact_support %}.
|
||||
|
||||
|
|
|
@ -156,3 +156,20 @@ You can also define a custom retention period for a specific artifact created by
|
|||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.repositories.settings-sidebar-actions-general %}
|
||||
{% data reusables.actions.change-retention-period-for-artifacts-logs %}
|
||||
|
||||
{% if actions-cache-policy-apis %}
|
||||
|
||||
## Configuring cache storage for a repository
|
||||
|
||||
{% data reusables.actions.cache-default-size %} However, these default sizes might be different if an enterprise owner has changed them. {% data reusables.actions.cache-eviction-process %}
|
||||
|
||||
You can set a total cache storage size for your repository up to the maximum size allowed by the enterprise policy setting.
|
||||
|
||||
The repository settings for {% data variables.product.prodname_actions %} cache storage can currently only be modified using the REST API:
|
||||
|
||||
* To view the current cache storage limit for a repository, see "[Get GitHub Actions cache usage policy for a repository](/rest/actions/cache#get-github-actions-cache-usage-policy-for-a-repository)."
|
||||
* To change the cache storage limit for a repository, see "[Set GitHub Actions cache usage policy for a repository](/rest/actions/cache#set-github-actions-cache-usage-policy-for-a-repository)."
|
||||
|
||||
{% data reusables.actions.cache-no-org-policy %}
|
||||
|
||||
{% endif %}
|
||||
|
|
|
@ -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: '*'
|
||||
ghes: '>3.4'
|
||||
ghae: 'issue-6337'
|
||||
ghec: '*'
|
||||
ghes: '>3.4'
|
||||
---
|
||||
|
||||
{% note %}
|
||||
|
@ -18,7 +18,8 @@ versions:
|
|||
|
||||
When you add a tag protection rule, all tags that match the pattern provided will be protected. Only users with admin or maintain permissions in the repository will be able to create protected tags, and only users with admin permissions in the repository will be able to delete protected tags. For more information, see "[Repository roles for an organization](/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)." {% data variables.product.prodname_github_apps %} require the `Repository administration: write` permission to modify a protected tag.
|
||||
|
||||
Additionally, you can create custom repository roles to allow other groups of users to create or delete tags that match tag protection rules. For more information, see "[Managing custom repository roles for an organization](/organizations/managing-peoples-access-to-your-organization-with-roles/managing-custom-repository-roles-for-an-organization)."
|
||||
{% if custom-repository-roles %}
|
||||
Additionally, you can create custom repository roles to allow other groups of users to create or delete tags that match tag protection rules. For more information, see "[Managing custom repository roles for an organization](/organizations/managing-peoples-access-to-your-organization-with-roles/managing-custom-repository-roles-for-an-organization)."{% endif %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
|
|