fix additional no trailing newlines
This commit is contained in:
@@ -34,6 +34,16 @@
|
||||
"GitHub.copilot",
|
||||
"GitHub.copilot-chat"
|
||||
]
|
||||
},
|
||||
"codespaces": {
|
||||
"repositories": {
|
||||
// allow Codespaces to pull from separate repo when user has access
|
||||
"github/docs-early-access": {
|
||||
"permissions": {
|
||||
"contents": "write"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
|
||||
|
||||
BIN
assets/images/help/actions/starter-workflow-go.png
Normal file
BIN
assets/images/help/actions/starter-workflow-go.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 121 KiB |
@@ -52,7 +52,27 @@ You can also find a list of your recently visited repositories, teams, and proje
|
||||
|
||||
## Staying updated with activity from the community
|
||||
|
||||
{% ifversion for-you-feed %}
|
||||
{% ifversion feed %}
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** The new feed is currently in public beta and subject to change.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
The feed is designed to help you discover relevant content from projects you follow, keep up with your friends and community members, and track recent activity in your communities.
|
||||
|
||||
You can use the {% octicon "filter" aria-hidden="true" %} **Filter** dropdown in the upper right corner to filter the feed to show only the exact event types you'd like to see. For example, you'll see updates when someone you follow:
|
||||
|
||||
- Stars a repository.
|
||||
- Follows another user.
|
||||
- Creates a public repository.
|
||||
- Opens an issue or pull request with `help wanted` or `good first issue` label on a repository you're watching.
|
||||
- Pushes commits to a repository you watch.
|
||||
- Forks a public repository.
|
||||
- Publishes a new release.
|
||||
|
||||
{% else %}
|
||||
The main section of your dashboard has two activity feeds:
|
||||
|
||||
- Following: Activity by people you follow and from repositories you watch.
|
||||
@@ -62,24 +82,16 @@ The main section of your dashboard has two activity feeds:
|
||||
|
||||
This feed shows activity from repositories and users you have shown a direct interest in, by following a user or watching a repository. For example, you'll see updates when a user you follow:
|
||||
|
||||
{% else %}
|
||||
In the "All activity" section of your news feed, you can view updates from repositories you watch and users you follow.
|
||||
|
||||
You'll see updates in your news feed when a user you follow:
|
||||
{% endif %}
|
||||
|
||||
- Stars a repository.
|
||||
- Follows another user.{% ifversion fpt or ghes or ghec %}
|
||||
- Creates a public repository.{% endif %}
|
||||
- Follows another user.
|
||||
- Creates a public repository.
|
||||
- Opens an issue or pull request with "help wanted" or "good first issue" label on a repository you're watching.
|
||||
- Pushes commits to a repository you watch.{% ifversion fpt or ghes or ghec %}
|
||||
- Forks a public repository.{% endif %}
|
||||
- Pushes commits to a repository you watch.
|
||||
- Forks a public repository.
|
||||
- Publishes a new release.
|
||||
|
||||
For more information about following people and watching repositories, see "[AUTOTITLE](/get-started/exploring-projects-on-github/following-people)" and "[AUTOTITLE](/get-started/quickstart/be-social)."
|
||||
|
||||
{% ifversion for-you-feed %}
|
||||
|
||||
### For you feed
|
||||
|
||||
{% note %}
|
||||
|
||||
@@ -54,7 +54,8 @@ The repository owner has full control of the repository. In addition to the acti
|
||||
| Create security advisories | "[AUTOTITLE](/code-security/security-advisories/working-with-repository-security-advisories/about-repository-security-advisories)" |
|
||||
| Display a sponsor button | "[AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/displaying-a-sponsor-button-in-your-repository)" |{% endif %}
|
||||
| Allow or disallow auto-merge for pull requests | "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-auto-merge-for-pull-requests-in-your-repository)" |
|
||||
| Manage webhooks and deploy keys | "[AUTOTITLE](/authentication/connecting-to-github-with-ssh/managing-deploy-keys#deploy-keys)" |
|
||||
| Manage deploy keys | "[AUTOTITLE](/authentication/connecting-to-github-with-ssh/managing-deploy-keys#deploy-keys)" |
|
||||
| Manage webhooks | "[AUTOTITLE](/webhooks/about-webhooks)" |
|
||||
|
||||
## Collaborator access for a repository owned by a personal account
|
||||
|
||||
|
||||
@@ -74,6 +74,7 @@ Alternatively, if you want to use the HTTPS protocol for both accounts, you can
|
||||
```shell copy
|
||||
echo "protocol=https`nhost=github.com" | git credential-manager erase
|
||||
```
|
||||
|
||||
- If the output is `wincred`, you're using the Windows Credential Manager. To clear the credentials, enter the following command.
|
||||
|
||||
```shell copy
|
||||
|
||||
@@ -51,6 +51,7 @@ For a definition of common terms, see "[AUTOTITLE](/actions/learn-github-actions
|
||||
Browse the complete list of CI starter workflow offered by {% data variables.product.company_short %} in the {% ifversion fpt or ghec %}[actions/starter-workflows](https://github.com/actions/starter-workflows/tree/main/ci) repository{% else %} `actions/starter-workflows` repository on {% data variables.location.product_location %}{% endif %}.
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[AUTOTITLE](/billing/managing-billing-for-github-actions)"
|
||||
|
||||
@@ -29,28 +29,44 @@ You should already be familiar with YAML syntax and how it's used with {% data v
|
||||
|
||||
We recommend that you have a basic understanding of the Go language. For more information, see [Getting started with Go](https://golang.org/doc/tutorial/getting-started).
|
||||
|
||||
## Using the Go starter workflow
|
||||
## Using a Go starter workflow
|
||||
|
||||
{% data variables.product.prodname_dotcom %} provides a Go starter workflow that should work for most Go projects. This guide includes examples that you can use to customize the starter workflow. For more information, see the [Go starter workflow](https://github.com/actions/starter-workflows/blob/main/ci/go.yml).
|
||||
{% data reusables.actions.starter-workflow-get-started %}
|
||||
|
||||
To get started quickly, add the starter workflow to the `.github/workflows` directory of your repository.
|
||||
{% data variables.product.prodname_dotcom %} provides a Go starter workflow that should work for most Go projects. The subsequent sections of this guide give examples of how you can customize this starter workflow.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
{% data reusables.actions.new-starter-workflow %}
|
||||
1. The "{% ifversion actions-starter-template-ui %}Choose a workflow{% else %}Choose a workflow template{% endif %}" page shows a selection of recommended starter workflows. Search for "go".
|
||||
1. Filter the selection of workflows by clicking **Continuous integration**.
|
||||
1. On the "Go - by {% data variables.product.prodname_actions %}" workflow, click {% ifversion actions-starter-template-ui %}**Configure**{% else %}**Set up this workflow**{% endif %}.
|
||||
|
||||

|
||||
|
||||
{%- ifversion ghes or ghae %}
|
||||
If you don't find the "Go - by {% data variables.product.prodname_actions %}" starter workflow, copy the following workflow code to a new file called `go.yml` in the `.github/workflows` directory of your repository.
|
||||
|
||||
```yaml copy
|
||||
name: Go package
|
||||
name: Go
|
||||
|
||||
on: [push]
|
||||
on:
|
||||
push:
|
||||
branches: [ "main" ]
|
||||
pull_request:
|
||||
branches: [ "main" ]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
|
||||
runs-on: ubuntu-latest
|
||||
runs-on: self-hosted
|
||||
steps:
|
||||
- uses: {% data reusables.actions.action-checkout %}
|
||||
|
||||
- name: Set up Go
|
||||
uses: {% data reusables.actions.action-setup-go %}
|
||||
with:
|
||||
go-version: '1.15'
|
||||
go-version: '1.20'
|
||||
|
||||
- name: Build
|
||||
run: go build -v ./...
|
||||
@@ -59,6 +75,15 @@ jobs:
|
||||
run: go test -v ./...
|
||||
```
|
||||
|
||||
{%- endif %}
|
||||
|
||||
1. Edit the workflow as required. For example, change the version of Go.
|
||||
1. Click **Commit changes**.
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
The `go.yml` workflow file is added to the `.github/workflows` directory of your repository.
|
||||
{% endif %}
|
||||
|
||||
## Specifying a Go version
|
||||
|
||||
The easiest way to specify a Go version is by using the `setup-go` action provided by {% data variables.product.prodname_dotcom %}. For more information see, the [`setup-go` action](https://github.com/actions/setup-go/).
|
||||
@@ -80,7 +105,7 @@ jobs:
|
||||
runs-on: ubuntu-latest
|
||||
strategy:
|
||||
matrix:
|
||||
go-version: [ '1.14', '1.15', '1.16.x' ]
|
||||
go-version: [ '1.19', '1.20', '1.21.x' ]
|
||||
|
||||
steps:
|
||||
- uses: {% data reusables.actions.action-checkout %}
|
||||
@@ -95,14 +120,14 @@ jobs:
|
||||
|
||||
### Using a specific Go version
|
||||
|
||||
You can configure your job to use a specific version of Go, such as `1.16.2`. Alternatively, you can use semantic version syntax to get the latest minor release. This example uses the latest patch release of Go 1.16:
|
||||
You can configure your job to use a specific version of Go, such as `1.20.8`. Alternatively, you can use semantic version syntax to get the latest minor release. This example uses the latest patch release of Go 1.21:
|
||||
|
||||
```yaml copy
|
||||
- name: Setup Go 1.16.x
|
||||
- name: Setup Go 1.21.x
|
||||
uses: {% data reusables.actions.action-setup-go %}
|
||||
with:
|
||||
# Semantic version range syntax or exact version of Go
|
||||
go-version: '1.16.x'
|
||||
go-version: '1.21.x'
|
||||
```
|
||||
|
||||
## Installing dependencies
|
||||
@@ -115,7 +140,7 @@ You can use `go get` to install dependencies:
|
||||
- name: Setup Go
|
||||
uses: {% data reusables.actions.action-setup-go %}
|
||||
with:
|
||||
go-version: '1.16.x'
|
||||
go-version: '1.21.x'
|
||||
- name: Install dependencies
|
||||
run: |
|
||||
go get .
|
||||
@@ -150,7 +175,7 @@ When caching is enabled, the `setup-go` action searches for the dependency file,
|
||||
- name: Setup Go
|
||||
uses: {% data reusables.actions.action-setup-go %}
|
||||
with:
|
||||
go-version: '1.16.x'
|
||||
go-version: '1.21.x'
|
||||
cache: true
|
||||
```
|
||||
|
||||
@@ -187,7 +212,7 @@ jobs:
|
||||
- name: Setup Go
|
||||
uses: {% data reusables.actions.action-setup-go %}
|
||||
with:
|
||||
go-version: '1.16.x'
|
||||
go-version: '1.21.x'
|
||||
- name: Install dependencies
|
||||
run: go get .
|
||||
- name: Build
|
||||
@@ -213,7 +238,7 @@ jobs:
|
||||
runs-on: ubuntu-latest
|
||||
strategy:
|
||||
matrix:
|
||||
go-version: [ '1.14', '1.15', '1.16.x' ]
|
||||
go-version: [ '1.19', '1.20', '1.21.x' ]
|
||||
|
||||
steps:
|
||||
- uses: {% data reusables.actions.action-checkout %}
|
||||
|
||||
@@ -15,7 +15,6 @@ topics:
|
||||
- Java
|
||||
- Ant
|
||||
shortTitle: Build & test Java & Ant
|
||||
layout: inline
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
@@ -40,40 +39,55 @@ We recommend that you have a basic understanding of Java and the Ant framework.
|
||||
|
||||
{% data reusables.actions.enterprise-setup-prereq %}
|
||||
|
||||
## Using the Ant starter workflow
|
||||
## Using an Ant starter workflow
|
||||
|
||||
{% data variables.product.prodname_dotcom %} provides an Ant starter workflow that will work for most Ant-based Java projects. For more information, see the [Ant starter workflow](https://github.com/actions/starter-workflows/blob/main/ci/ant.yml). {% data reusables.actions.workflows.starter-workflows %}
|
||||
{% data reusables.actions.starter-workflow-get-started %}
|
||||
|
||||
To get started quickly, you can choose the preconfigured Ant starter workflow when you create a new workflow. For more information, see the "[AUTOTITLE](/actions/quickstart)."
|
||||
{% data variables.product.prodname_dotcom %} provides a starter workflow for Ant that should work for most Java with Ant projects. The subsequent sections of this guide give examples of how you can customize this starter workflow.
|
||||
|
||||
You can also add this workflow manually by creating a new file in the `.github/workflows` directory of your repository.
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
{% data reusables.actions.new-starter-workflow %}
|
||||
1. The "{% ifversion actions-starter-template-ui %}Choose a workflow{% else %}Choose a workflow template{% endif %}" page shows a selection of recommended starter workflows. Search for "Java with Ant".
|
||||
1. On the "Java with Ant" workflow, click {% ifversion actions-starter-template-ui %}**Configure**{% else %}**Set up this workflow**{% endif %}.
|
||||
|
||||
```yaml annotate copy
|
||||
# {% data reusables.actions.workflows.workflow-syntax-name %}
|
||||
{%- ifversion ghes or ghae %}
|
||||
|
||||
If you don't find the "Java with Ant" starter workflow, copy the following workflow code to a new file called `ant.yml` in the `.github/workflows` directory of your repository.
|
||||
|
||||
```yaml copy
|
||||
name: Java CI
|
||||
|
||||
#
|
||||
on: [push]
|
||||
#
|
||||
on:
|
||||
push:
|
||||
branches: [ $default-branch ]
|
||||
pull_request:
|
||||
branches: [ $default-branch ]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
{% data reusables.actions.example-github-runner-comment %}
|
||||
runs-on: ubuntu-latest
|
||||
#
|
||||
|
||||
steps:
|
||||
{% data reusables.actions.workflows.workflow-checkout-step-explainer %}
|
||||
- uses: {% data reusables.actions.action-checkout %}
|
||||
{% data reusables.actions.workflows.setup-java-step-explainer %}
|
||||
- name: Set up JDK 17
|
||||
- name: Set up JDK 11
|
||||
uses: {% data reusables.actions.action-setup-java %}
|
||||
with:
|
||||
java-version: '17'
|
||||
java-version: '11'
|
||||
distribution: 'temurin'
|
||||
# This step runs the default target in your `build.xml` file in non-interactive mode.
|
||||
- name: Build with Ant
|
||||
run: ant -noinput -buildfile build.xml
|
||||
```
|
||||
|
||||
{%- endif %}
|
||||
|
||||
1. Edit the workflow as required. For example, change the Java version.
|
||||
1. Click **Commit changes**.
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
The `ant.yml` workflow file is added to the `.github/workflows` directory of your repository.
|
||||
{% endif %}
|
||||
|
||||
{% data reusables.actions.java-jvm-architecture %}
|
||||
|
||||
## Building and testing your code
|
||||
|
||||
@@ -15,7 +15,6 @@ topics:
|
||||
- Java
|
||||
- Gradle
|
||||
shortTitle: Build & test Java & Gradle
|
||||
layout: inline
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
@@ -40,55 +39,63 @@ We recommend that you have a basic understanding of Java and the Gradle framewor
|
||||
|
||||
{% data reusables.actions.enterprise-setup-prereq %}
|
||||
|
||||
## Using the Gradle starter workflow
|
||||
## Using a Gradle starter workflow
|
||||
|
||||
{% data variables.product.prodname_dotcom %} provides a Gradle starter workflow that will work for most Gradle-based Java projects. For more information, see the [Gradle starter workflow](https://github.com/actions/starter-workflows/blob/main/ci/gradle.yml). {% data reusables.actions.workflows.starter-workflows %}
|
||||
{% data reusables.actions.starter-workflow-get-started %}
|
||||
|
||||
To get started quickly, you can choose the preconfigured Gradle starter workflow when you create a new workflow. For more information, see the "[AUTOTITLE](/actions/quickstart)."
|
||||
{% data variables.product.prodname_dotcom %} provides a starter workflow for Gradle that should work for most Java with Gradle projects. The subsequent sections of this guide give examples of how you can customize this starter workflow.
|
||||
|
||||
You can also add this workflow manually by creating a new file in the `.github/workflows` directory of your repository.
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
{% data reusables.actions.new-starter-workflow %}
|
||||
1. The "{% ifversion actions-starter-template-ui %}Choose a workflow{% else %}Choose a workflow template{% endif %}" page shows a selection of recommended starter workflows. Search for "Java with Gradle".
|
||||
1. On the "Java with Gradle" workflow, click {% ifversion actions-starter-template-ui %}**Configure**{% else %}**Set up this workflow**{% endif %}.
|
||||
|
||||
{% note %}
|
||||
{%- ifversion ghes or ghae %}
|
||||
|
||||
**Notes:**
|
||||
If you don't find the "Java with Gradle" starter workflow, copy the following workflow code to a new file called `gradle.yml` in the `.github/workflows` directory of your repository.
|
||||
|
||||
- {% data reusables.actions.actions-not-certified-by-github %}
|
||||
- {% data reusables.actions.actions-use-sha-pinning %}
|
||||
```yaml copy
|
||||
name: Java CI with Gradle
|
||||
|
||||
{% endnote %}
|
||||
on:
|
||||
push:
|
||||
branches: [ "main" ]
|
||||
pull_request:
|
||||
branches: [ "main" ]
|
||||
|
||||
```yaml annotate copy
|
||||
# {% data reusables.actions.workflows.workflow-syntax-name %}
|
||||
name: Java CI
|
||||
permissions:
|
||||
contents: read
|
||||
|
||||
#
|
||||
on: [push]
|
||||
#
|
||||
jobs:
|
||||
build:
|
||||
|
||||
{% data reusables.actions.example-github-runner-comment %}
|
||||
runs-on: ubuntu-latest
|
||||
#
|
||||
|
||||
steps:
|
||||
{% data reusables.actions.workflows.workflow-checkout-step-explainer %}
|
||||
- uses: {% data reusables.actions.action-checkout %}
|
||||
{% data reusables.actions.workflows.setup-java-step-explainer %}
|
||||
- name: Set up JDK 17
|
||||
- name: Set up JDK 11
|
||||
uses: {% data reusables.actions.action-setup-java %}
|
||||
with:
|
||||
java-version: '17'
|
||||
java-version: '11'
|
||||
distribution: 'temurin'
|
||||
# The "Validate Gradle wrapper" step validates the checksums of Gradle Wrapper JAR files present in the source tree.
|
||||
- name: Validate Gradle wrapper
|
||||
uses: gradle/wrapper-validation-action@ccb4328a959376b642e027874838f60f8e596de3
|
||||
# The "Build with Gradle" step does a build using the `gradle/gradle-build-action` action provided by the Gradle organization on {% data variables.product.prodname_dotcom %}. The action takes care of invoking Gradle, collecting results, and caching state between jobs. For more information see [`gradle/gradle-build-action`](https://github.com/gradle/gradle-build-action).
|
||||
- name: Build with Gradle
|
||||
uses: gradle/gradle-build-action@749f47bda3e44aa060e82d7b3ef7e40d953bd629
|
||||
uses: gradle/gradle-build-action@bd5760595778326ba7f1441bcf7e88b49de61a25 # v2.6.0
|
||||
with:
|
||||
arguments: build
|
||||
```
|
||||
|
||||
{%- endif %}
|
||||
|
||||
1. Edit the workflow as required. For example, change the Java version.
|
||||
|
||||
{% indented_data_reference reusables.actions.third-party-actions spaces=3 %}
|
||||
|
||||
1. Click **Commit changes**.
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
The `gradle.yml` workflow file is added to the `.github/workflows` directory of your repository.
|
||||
{% endif %}
|
||||
|
||||
{% data reusables.actions.java-jvm-architecture %}
|
||||
|
||||
## Building and testing your code
|
||||
|
||||
@@ -15,7 +15,6 @@ topics:
|
||||
- Java
|
||||
- Maven
|
||||
shortTitle: Build & test Java with Maven
|
||||
layout: inline
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
@@ -40,42 +39,59 @@ We recommend that you have a basic understanding of Java and the Maven framework
|
||||
|
||||
{% data reusables.actions.enterprise-setup-prereq %}
|
||||
|
||||
## Using the Maven starter workflow
|
||||
## Using a Maven starter workflow
|
||||
|
||||
{% data variables.product.prodname_dotcom %} provides a Maven starter workflow that will work for most Maven-based Java projects. For more information, see the [Maven starter workflow](https://github.com/actions/starter-workflows/blob/main/ci/maven.yml).
|
||||
{% data reusables.actions.starter-workflow-get-started %}
|
||||
|
||||
To get started quickly, you can choose the preconfigured Maven starter workflow when you create a new workflow. For more information, see the "[AUTOTITLE](/actions/quickstart)."
|
||||
{% data variables.product.prodname_dotcom %} provides a starter workflow for Maven that should work for most Java with Maven projects. The subsequent sections of this guide give examples of how you can customize this starter workflow.
|
||||
|
||||
You can also add this workflow manually by creating a new file in the `.github/workflows` directory of your repository.
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
{% data reusables.actions.new-starter-workflow %}
|
||||
1. The "{% ifversion actions-starter-template-ui %}Choose a workflow{% else %}Choose a workflow template{% endif %}" page shows a selection of recommended starter workflows. Search for "Java with Maven".
|
||||
1. On the "Java with Maven" workflow, click {% ifversion actions-starter-template-ui %}**Configure**{% else %}**Set up this workflow**{% endif %}.
|
||||
|
||||
```yaml annotate copy
|
||||
# {% data reusables.actions.workflows.workflow-syntax-name %}
|
||||
name: Java CI
|
||||
{%- ifversion ghes or ghae %}
|
||||
|
||||
If you don't find the "Java with Maven" starter workflow, copy the following workflow code to a new file called `maven.yml` in the `.github/workflows` directory of your repository.
|
||||
|
||||
```yaml copy
|
||||
name: Java CI with Maven
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [ "main" ]
|
||||
pull_request:
|
||||
branches: [ "main" ]
|
||||
|
||||
#
|
||||
on: [push]
|
||||
#
|
||||
jobs:
|
||||
build:
|
||||
|
||||
{% data reusables.actions.example-github-runner-comment %}
|
||||
runs-on: ubuntu-latest
|
||||
#
|
||||
|
||||
steps:
|
||||
{% data reusables.actions.workflows.workflow-checkout-step-explainer %}
|
||||
- uses: {% data reusables.actions.action-checkout %}
|
||||
{% data reusables.actions.workflows.setup-java-step-explainer %}
|
||||
- name: Set up JDK 17
|
||||
uses: {% data reusables.actions.action-setup-java %}
|
||||
with:
|
||||
java-version: '17'
|
||||
distribution: 'temurin'
|
||||
# The "Build with Maven" step runs the Maven `package` target in non-interactive mode to ensure that your code builds, tests pass, and a package can be created.
|
||||
cache: maven
|
||||
- name: Build with Maven
|
||||
run: mvn --batch-mode --update-snapshots package
|
||||
run: mvn -B package --file pom.xml
|
||||
|
||||
# Optional: Uploads the full dependency graph to GitHub to improve the quality of Dependabot alerts this repository can receive
|
||||
- name: Update dependency graph
|
||||
uses: advanced-security/maven-dependency-submission-action@571e99aab1055c2e71a1e2309b9691de18d6b7d6
|
||||
```
|
||||
|
||||
{% data reusables.actions.workflows.starter-workflows %}
|
||||
{%- endif %}
|
||||
|
||||
1. Edit the workflow as required. For example, change the Java version.
|
||||
1. Click **Commit changes**.
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
The `maven.yml` workflow file is added to the `.github/workflows` directory of your repository.
|
||||
{% endif %}
|
||||
|
||||
{% data reusables.actions.java-jvm-architecture %}
|
||||
|
||||
|
||||
@@ -27,39 +27,58 @@ You should already be familiar with YAML syntax and how it's used with {% data v
|
||||
|
||||
We recommend that you have a basic understanding of the .NET Core SDK. For more information, see [Getting started with .NET](https://dotnet.microsoft.com/learn).
|
||||
|
||||
## Using the .NET starter workflow
|
||||
## Using a .NET starter workflow
|
||||
|
||||
{% data variables.product.prodname_dotcom %} provides a .NET starter workflow that should work for most .NET projects, and this guide includes examples that show you how to customize this starter workflow. For more information, see the [.NET starter workflow](https://github.com/actions/setup-dotnet).
|
||||
{% data reusables.actions.starter-workflow-get-started %}
|
||||
|
||||
To get started quickly, add the starter workflow to the `.github/workflows` directory of your repository.
|
||||
{% data variables.product.prodname_dotcom %} provides a starter workflow for .NET that should work for most .NET projects. The subsequent sections of this guide give examples of how you can customize this starter workflow.
|
||||
|
||||
```yaml
|
||||
name: dotnet package
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
{% data reusables.actions.new-starter-workflow %}
|
||||
1. The "{% ifversion actions-starter-template-ui %}Choose a workflow{% else %}Choose a workflow template{% endif %}" page shows a selection of recommended starter workflows. Search for "dotnet".
|
||||
1. On the ".NET" workflow, click {% ifversion actions-starter-template-ui %}**Configure**{% else %}**Set up this workflow**{% endif %}.
|
||||
|
||||
on: [push]
|
||||
{%- ifversion ghes or ghae %}
|
||||
|
||||
If you don't find the ".NET" starter workflow, copy the following workflow code to a new file called `dotnet.yml` in the `.github/workflows` directory of your repository.
|
||||
|
||||
```yaml copy
|
||||
name: .NET
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [ "main" ]
|
||||
pull_request:
|
||||
branches: [ "main" ]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
|
||||
runs-on: ubuntu-latest
|
||||
strategy:
|
||||
matrix:
|
||||
dotnet-version: [ '3.1.x', '6.0.x' ]
|
||||
|
||||
steps:
|
||||
- uses: {% data reusables.actions.action-checkout %}
|
||||
- name: Setup .NET Core SDK {% raw %}${{ matrix.dotnet-version }}{% endraw %}
|
||||
- name: Setup .NET
|
||||
uses: {% data reusables.actions.action-setup-dotnet %}
|
||||
with:
|
||||
dotnet-version: {% raw %}${{ matrix.dotnet-version }}{% endraw %}
|
||||
- name: Install dependencies
|
||||
dotnet-version: 6.0.x
|
||||
- name: Restore dependencies
|
||||
run: dotnet restore
|
||||
- name: Build
|
||||
run: dotnet build --configuration Release --no-restore
|
||||
run: dotnet build --no-restore
|
||||
- name: Test
|
||||
run: dotnet test --no-restore --verbosity normal
|
||||
run: dotnet test --no-build --verbosity normal
|
||||
```
|
||||
|
||||
{%- endif %}
|
||||
|
||||
1. Edit the workflow as required. For example, change the .NET version.
|
||||
1. Click **Commit changes**.
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
The `dotnet.yml` workflow file is added to the `.github/workflows` directory of your repository.
|
||||
{% endif %}
|
||||
|
||||
## Specifying a .NET version
|
||||
|
||||
To use a preinstalled version of the .NET Core SDK on a {% data variables.product.prodname_dotcom %}-hosted runner, use the `setup-dotnet` action. This action finds a specific version of .NET from the tools cache on each runner, and adds the necessary binaries to `PATH`. These changes will persist for the remainder of the job.
|
||||
|
||||
@@ -16,7 +16,6 @@ topics:
|
||||
- Node
|
||||
- JavaScript
|
||||
shortTitle: Build & test Node.js
|
||||
layout: inline
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
@@ -34,67 +33,76 @@ We recommend that you have a basic understanding of Node.js, YAML, workflow conf
|
||||
|
||||
{% data reusables.actions.enterprise-setup-prereq %}
|
||||
|
||||
## Using the Node.js starter workflow
|
||||
## Using a Node.js starter workflow
|
||||
|
||||
{% data variables.product.prodname_dotcom %} provides a Node.js starter workflow that will work for most Node.js projects. This guide includes npm and Yarn examples that you can use to customize the starter workflow. For more information, see the [Node.js starter workflow](https://github.com/actions/starter-workflows/blob/main/ci/node.js.yml).
|
||||
{% data reusables.actions.starter-workflow-get-started %}
|
||||
|
||||
{% data reusables.actions.workflows.starter-workflows %}
|
||||
{% data variables.product.prodname_dotcom %} provides a starter workflow for Node.js that should work for most Node.js projects. The subsequent sections of this guide give examples of how you can customize this starter workflow.
|
||||
|
||||
To get started quickly, add the starter workflow to the `.github/workflows` directory of your repository.
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
{% data reusables.actions.new-starter-workflow %}
|
||||
1. The "{% ifversion actions-starter-template-ui %}Choose a workflow{% else %}Choose a workflow template{% endif %}" page shows a selection of recommended starter workflows. Search for "Node.js".
|
||||
1. Filter the selection of workflows by clicking **Continuous integration**.
|
||||
1. On the "Node.js" workflow, click {% ifversion actions-starter-template-ui %}**Configure**{% else %}**Set up this workflow**{% endif %}.
|
||||
|
||||
```yaml annotate copy
|
||||
# {% data reusables.actions.workflows.workflow-syntax-name %}
|
||||
{%- ifversion ghes or ghae %}
|
||||
|
||||
If you don't find the "Node.js" starter workflow, copy the following workflow code to a new file called `node.js.yml` in the `.github/workflows` directory of your repository.
|
||||
|
||||
```yaml copy
|
||||
name: Node.js CI
|
||||
|
||||
# This example workflow assumes that the default branch for your repository is `main`. If the default branch has a different name, edit this example and add your repository's default branch.
|
||||
on:
|
||||
push:
|
||||
branches: [ main ]
|
||||
branches: [ "main" ]
|
||||
pull_request:
|
||||
branches: [ main ]
|
||||
branches: [ "main" ]
|
||||
|
||||
#
|
||||
jobs:
|
||||
build:
|
||||
|
||||
{% data reusables.actions.example-github-runner-comment %}
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
# This job uses a matrix strategy to run the job four times, once for each specified Node version. For more information, see "[AUTOTITLE](/actions/using-jobs/using-a-matrix-for-your-jobs)."
|
||||
strategy:
|
||||
matrix:
|
||||
node-version: [14.x, 16.x, 18.x, 20.x]
|
||||
#
|
||||
node-version: [14.x, 16.x, 18.x]
|
||||
# See supported Node.js release schedule at https://nodejs.org/en/about/releases/
|
||||
|
||||
steps:
|
||||
{% data reusables.actions.workflows.workflow-checkout-step-explainer %}
|
||||
- uses: {% data reusables.actions.action-checkout %}
|
||||
# This step uses the `actions/setup-node` action to set up Node.js for each version indicated by the `matrix.node-version` key above.
|
||||
- name: Use Node.js {% raw %}${{ matrix.node-version }}{% endraw %}
|
||||
uses: {% data reusables.actions.action-setup-node %}
|
||||
with:
|
||||
node-version: {% raw %}${{ matrix.node-version }}{% endraw %}
|
||||
# This step runs `npm ci` to install any dependencies listed in your `package.json` file.
|
||||
cache: 'npm'
|
||||
- run: npm ci
|
||||
# This step runs the `build` script if there is one specified under the `scripts` key in your `package.json` file.
|
||||
- run: npm run build --if-present
|
||||
# This step runs the `test` script that is specified under the `scripts` key in your `package.json` file.
|
||||
- run: npm test
|
||||
```
|
||||
|
||||
{%- endif %}
|
||||
|
||||
1. Edit the workflow as required. For example, change the Node versions you want to use.
|
||||
1. Click **Commit changes**.
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
The `node.js.yml` workflow file is added to the `.github/workflows` directory of your repository.
|
||||
{% endif %}
|
||||
|
||||
## Specifying the Node.js version
|
||||
|
||||
The easiest way to specify a Node.js version is by using the `setup-node` action provided by {% data variables.product.prodname_dotcom %}. For more information see, [`setup-node`](https://github.com/actions/setup-node/).
|
||||
|
||||
The `setup-node` action takes a Node.js version as an input and configures that version on the runner. The `setup-node` action finds a specific version of Node.js from the tools cache on each runner and adds the necessary binaries to `PATH`, which persists for the rest of the job. Using the `setup-node` action is the recommended way of using Node.js with {% data variables.product.prodname_actions %} because it ensures consistent behavior across different runners and different versions of Node.js. If you are using a self-hosted runner, you must install Node.js and add it to `PATH`.
|
||||
|
||||
The starter workflow includes a matrix strategy that builds and tests your code with four Node.js versions: 14.x, 16.x, 18.x, and 20.x. The 'x' is a wildcard character that matches the latest minor and patch release available for a version. Each version of Node.js specified in the `node-version` array creates a job that runs the same steps.
|
||||
The starter workflow includes a matrix strategy that builds and tests your code with the Node.js versions listed in `node-version`. The 'x' in the version number is a wildcard character that matches the latest minor and patch release available for a version. Each version of Node.js specified in the `node-version` array creates a job that runs the same steps.
|
||||
|
||||
Each job can access the value defined in the matrix `node-version` array using the `matrix` context. The `setup-node` action uses the context as the `node-version` input. The `setup-node` action configures each job with a different Node.js version before building and testing code. For more information about matrix strategies and contexts, see "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix)" and "[AUTOTITLE](/actions/learn-github-actions/contexts)."
|
||||
|
||||
```yaml copy
|
||||
strategy:
|
||||
matrix:
|
||||
node-version: [14.x, 16.x, 18.x, 20.x]
|
||||
node-version: [14.x, 16.x, 18.x]
|
||||
|
||||
steps:
|
||||
- uses: {% data reusables.actions.action-checkout %}
|
||||
@@ -129,7 +137,7 @@ jobs:
|
||||
- name: Use Node.js
|
||||
uses: {% data reusables.actions.action-setup-node %}
|
||||
with:
|
||||
node-version: '18.x'
|
||||
node-version: '20.x'
|
||||
- run: npm ci
|
||||
- run: npm run build --if-present
|
||||
- run: npm test
|
||||
@@ -156,7 +164,7 @@ steps:
|
||||
- name: Use Node.js
|
||||
uses: {% data reusables.actions.action-setup-node %}
|
||||
with:
|
||||
node-version: '18.x'
|
||||
node-version: '20.x'
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
```
|
||||
@@ -169,7 +177,7 @@ steps:
|
||||
- name: Use Node.js
|
||||
uses: {% data reusables.actions.action-setup-node %}
|
||||
with:
|
||||
node-version: '18.x'
|
||||
node-version: '20.x'
|
||||
- name: Install dependencies
|
||||
run: npm install
|
||||
```
|
||||
@@ -184,7 +192,7 @@ steps:
|
||||
- name: Use Node.js
|
||||
uses: {% data reusables.actions.action-setup-node %}
|
||||
with:
|
||||
node-version: '18.x'
|
||||
node-version: '20.x'
|
||||
- name: Install dependencies
|
||||
run: yarn --frozen-lockfile
|
||||
```
|
||||
@@ -197,7 +205,7 @@ steps:
|
||||
- name: Use Node.js
|
||||
uses: {% data reusables.actions.action-setup-node %}
|
||||
with:
|
||||
node-version: '18.x'
|
||||
node-version: '20.x'
|
||||
- name: Install dependencies
|
||||
run: yarn
|
||||
```
|
||||
@@ -219,7 +227,7 @@ steps:
|
||||
uses: {% data reusables.actions.action-setup-node %}
|
||||
with:
|
||||
always-auth: true
|
||||
node-version: '18.x'
|
||||
node-version: '20.x'
|
||||
registry-url: https://registry.npmjs.org
|
||||
scope: '@octocat'
|
||||
- name: Install dependencies
|
||||
@@ -249,7 +257,7 @@ steps:
|
||||
- uses: {% data reusables.actions.action-checkout %}
|
||||
- uses: {% data reusables.actions.action-setup-node %}
|
||||
with:
|
||||
node-version: '14'
|
||||
node-version: '20'
|
||||
cache: 'npm'
|
||||
- run: npm install
|
||||
- run: npm test
|
||||
@@ -262,7 +270,7 @@ steps:
|
||||
- uses: {% data reusables.actions.action-checkout %}
|
||||
- uses: {% data reusables.actions.action-setup-node %}
|
||||
with:
|
||||
node-version: '14'
|
||||
node-version: '20'
|
||||
cache: 'yarn'
|
||||
- run: yarn
|
||||
- run: yarn test
|
||||
@@ -282,7 +290,7 @@ steps:
|
||||
version: 6.10.0
|
||||
- uses: {% data reusables.actions.action-setup-node %}
|
||||
with:
|
||||
node-version: '14'
|
||||
node-version: '20'
|
||||
cache: 'pnpm'
|
||||
- run: pnpm install
|
||||
- run: pnpm test
|
||||
@@ -302,7 +310,7 @@ steps:
|
||||
- name: Use Node.js
|
||||
uses: {% data reusables.actions.action-setup-node %}
|
||||
with:
|
||||
node-version: '18.x'
|
||||
node-version: '20.x'
|
||||
- run: npm install
|
||||
- run: npm run build --if-present
|
||||
- run: npm test
|
||||
|
||||
@@ -39,47 +39,69 @@ We recommend that you have a basic understanding of Python, PyPy, and pip. For m
|
||||
|
||||
{% data reusables.actions.enterprise-setup-prereq %}
|
||||
|
||||
## Using the Python starter workflow
|
||||
## Using a Python starter workflow
|
||||
|
||||
{% data variables.product.prodname_dotcom %} provides a Python starter workflow that should work for most Python projects. This guide includes examples that you can use to customize the starter workflow. For more information, see the [Python starter workflow](https://github.com/actions/starter-workflows/blob/main/ci/python-package.yml).
|
||||
{% data reusables.actions.starter-workflow-get-started %}
|
||||
|
||||
To get started quickly, add the starter workflow to the `.github/workflows` directory of your repository.
|
||||
{% data variables.product.prodname_dotcom %} provides a starter workflow for Python that should work for most Python projects. The subsequent sections of this guide give examples of how you can customize this starter workflow.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
{% data reusables.actions.new-starter-workflow %}
|
||||
1. The "{% ifversion actions-starter-template-ui %}Choose a workflow{% else %}Choose a workflow template{% endif %}" page shows a selection of recommended starter workflows. Search for "Python application".
|
||||
1. On the "Python application" workflow, click {% ifversion actions-starter-template-ui %}**Configure**{% else %}**Set up this workflow**{% endif %}.
|
||||
|
||||
{%- ifversion ghes or ghae %}
|
||||
|
||||
If you don't find the "Python application" starter workflow, copy the following workflow code to a new file called `python-app.yml` in the `.github/workflows` directory of your repository.
|
||||
|
||||
```yaml copy
|
||||
name: Python package
|
||||
name: Python application
|
||||
|
||||
on: [push]
|
||||
on:
|
||||
push:
|
||||
branches: [ "main" ]
|
||||
pull_request:
|
||||
branches: [ "main" ]
|
||||
|
||||
permissions:
|
||||
contents: read
|
||||
|
||||
jobs:
|
||||
build:
|
||||
|
||||
runs-on: ubuntu-latest
|
||||
strategy:
|
||||
matrix:
|
||||
python-version: ["3.7", "3.8", "3.9", "3.10", "3.11"]
|
||||
|
||||
steps:
|
||||
- uses: {% data reusables.actions.action-checkout %}
|
||||
- name: Set up Python {% raw %}${{ matrix.python-version }}{% endraw %}
|
||||
- name: Set up Python 3.10
|
||||
uses: {% data reusables.actions.action-setup-python %}
|
||||
with:
|
||||
python-version: {% raw %}${{ matrix.python-version }}{% endraw %}
|
||||
python-version: "3.10"
|
||||
- name: Install dependencies
|
||||
run: |
|
||||
python -m pip install --upgrade pip
|
||||
pip install ruff pytest
|
||||
pip install flake8 pytest
|
||||
if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
|
||||
- name: Lint with ruff
|
||||
- name: Lint with flake8
|
||||
run: |
|
||||
# stop the build if there are Python syntax errors or undefined names
|
||||
ruff --format=github --select=E9,F63,F7,F82 --target-version=py37 .
|
||||
# default set of ruff rules with GitHub Annotations
|
||||
ruff --format=github --target-version=py37 .
|
||||
flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics
|
||||
# exit-zero treats all errors as warnings. The GitHub editor is 127 chars wide
|
||||
flake8 . --count --exit-zero --max-complexity=10 --max-line-length=127 --statistics
|
||||
- name: Test with pytest
|
||||
run: |
|
||||
pytest
|
||||
```
|
||||
|
||||
{%- endif %}
|
||||
|
||||
1. Edit the workflow as required. For example, change the Python version.
|
||||
1. Click **Commit changes**.
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
The `python-app.yml` workflow file is added to the `.github/workflows` directory of your repository.
|
||||
{% endif %}
|
||||
|
||||
## Specifying a Python version
|
||||
|
||||
To use a pre-installed version of Python or PyPy on a {% data variables.product.prodname_dotcom %}-hosted runner, use the `setup-python` action. This action finds a specific version of Python or PyPy from the tools cache on each runner and adds the necessary binaries to `PATH`, which persists for the rest of the job. If a specific version of Python is not pre-installed in the tools cache, the `setup-python` action will download and set up the appropriate version from the [`python-versions`](https://github.com/actions/python-versions) repository.
|
||||
|
||||
@@ -28,42 +28,68 @@ We recommend that you have a basic understanding of Ruby, YAML, workflow configu
|
||||
- [Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)
|
||||
- [Ruby in 20 minutes](https://www.ruby-lang.org/en/documentation/quickstart/)
|
||||
|
||||
## Using the Ruby starter workflow
|
||||
## Using a Ruby starter workflow
|
||||
|
||||
{% data variables.product.prodname_dotcom %} provides a Ruby starter workflow that will work for most Ruby projects. For more information, see the [Ruby starter workflow](https://github.com/actions/starter-workflows/blob/master/ci/ruby.yml).
|
||||
{% data reusables.actions.starter-workflow-get-started %}
|
||||
|
||||
To get started quickly, add the starter workflow to the `.github/workflows` directory of your repository. The workflow shown below assumes that the default branch for your repository is `main`.
|
||||
{% data variables.product.prodname_dotcom %} provides a starter workflow for Ruby that should work for most Ruby projects. The subsequent sections of this guide give examples of how you can customize this starter workflow.
|
||||
|
||||
```yaml
|
||||
{% data reusables.actions.actions-not-certified-by-github-comment %}
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
{% data reusables.actions.new-starter-workflow %}
|
||||
1. The "{% ifversion actions-starter-template-ui %}Choose a workflow{% else %}Choose a workflow template{% endif %}" page shows a selection of recommended starter workflows. Search for "ruby".
|
||||
1. Filter the selection of workflows by clicking **Continuous integration**.
|
||||
1. On the "Ruby" workflow, click {% ifversion actions-starter-template-ui %}**Configure**{% else %}**Set up this workflow**{% endif %}.
|
||||
|
||||
{% data reusables.actions.actions-use-sha-pinning-comment %}
|
||||
{%- ifversion ghes or ghae %}
|
||||
|
||||
If you don't find the "Ruby" starter workflow, copy the following workflow code to a new file called `ruby.yml` in the `.github/workflows` directory of your repository.
|
||||
|
||||
```yaml copy
|
||||
name: Ruby
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [ main ]
|
||||
branches: [ "main" ]
|
||||
pull_request:
|
||||
branches: [ main ]
|
||||
branches: [ "main" ]
|
||||
|
||||
permissions:
|
||||
contents: read
|
||||
|
||||
jobs:
|
||||
test:
|
||||
|
||||
runs-on: ubuntu-latest
|
||||
strategy:
|
||||
matrix:
|
||||
ruby-version: ['2.6', '2.7', '3.0']
|
||||
|
||||
steps:
|
||||
- uses: {% data reusables.actions.action-checkout %}
|
||||
- name: Set up Ruby
|
||||
uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
|
||||
# To automatically get bug fixes and new Ruby versions for ruby/setup-ruby,
|
||||
# change this to (see https://github.com/ruby/setup-ruby#versioning):
|
||||
# uses: ruby/setup-ruby@v1
|
||||
uses: ruby/setup-ruby@55283cc23133118229fd3f97f9336ee23a179fcf # v1.146.0
|
||||
with:
|
||||
ruby-version: '3.1'
|
||||
- name: Install dependencies
|
||||
run: bundle install
|
||||
ruby-version: {% raw %}${{ matrix.ruby-version }}{% endraw %}
|
||||
bundler-cache: true # runs 'bundle install' and caches installed gems automatically
|
||||
- name: Run tests
|
||||
run: bundle exec rake
|
||||
```
|
||||
|
||||
{%- endif %}
|
||||
|
||||
1. Edit the workflow as required. For example, change the Ruby versions you want to use.
|
||||
|
||||
{% indented_data_reference reusables.actions.third-party-actions spaces=3 %}
|
||||
|
||||
1. Click **Commit changes**.
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
The `ruby.yml` workflow file is added to the `.github/workflows` directory of your repository.
|
||||
{% endif %}
|
||||
|
||||
## Specifying the Ruby version
|
||||
|
||||
The easiest way to specify a Ruby version is by using the `ruby/setup-ruby` action provided by the Ruby organization on GitHub. The action adds any supported Ruby version to `PATH` for each job run in a workflow. For more information and available Ruby versions, see [`ruby/setup-ruby`](https://github.com/ruby/setup-ruby).
|
||||
|
||||
@@ -30,30 +30,53 @@ You should already be familiar with YAML syntax and how it's used with {% data v
|
||||
|
||||
We recommend that you have a basic understanding of Swift packages. For more information, see "[Swift Packages](https://developer.apple.com/documentation/swift_packages)" in the Apple developer documentation.
|
||||
|
||||
## Using the Swift starter workflow
|
||||
## Using a Swift starter workflow
|
||||
|
||||
{% data variables.product.prodname_dotcom %} provides a Swift starter workflow that should work for most Swift projects, and this guide includes examples that show you how to customize this starter workflow. For more information, see the [Swift starter workflow](https://github.com/actions/starter-workflows/blob/main/ci/swift.yml).
|
||||
{% data reusables.actions.starter-workflow-get-started %}
|
||||
|
||||
To get started quickly, add the starter workflow to the `.github/workflows` directory of your repository.
|
||||
{% data variables.product.prodname_dotcom %} provides a starter workflow for Swift that should work for most Swift projects. The subsequent sections of this guide give examples of how you can customize this starter workflow.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
{% data reusables.actions.new-starter-workflow %}
|
||||
1. The "{% ifversion actions-starter-template-ui %}Choose a workflow{% else %}Choose a workflow template{% endif %}" page shows a selection of recommended starter workflows. Search for "swift".
|
||||
1. Filter the selection of workflows by clicking **Continuous integration**.
|
||||
1. On the "Swift" workflow, click {% ifversion actions-starter-template-ui %}**Configure**{% else %}**Set up this workflow**{% endif %}.
|
||||
|
||||
{%- ifversion ghes or ghae %}
|
||||
|
||||
If you don't find the "Swift" starter workflow, copy the following workflow code to a new file called `swift.yml` in the `.github/workflows` directory of your repository.
|
||||
|
||||
```yaml copy
|
||||
name: Swift
|
||||
|
||||
on: [push]
|
||||
on:
|
||||
push:
|
||||
branches: [ "main" ]
|
||||
pull_request:
|
||||
branches: [ "main" ]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
|
||||
runs-on: macos-latest
|
||||
|
||||
steps:
|
||||
- uses: {% data reusables.actions.action-checkout %}
|
||||
- name: Build
|
||||
run: swift build
|
||||
run: swift build -v
|
||||
- name: Run tests
|
||||
run: swift test
|
||||
run: swift test -v
|
||||
```
|
||||
|
||||
{%- endif %}
|
||||
|
||||
1. Edit the workflow as required. For example, change the branch on which the workflow will run.
|
||||
1. Click **Commit changes**.
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
The `swift.yml` workflow file is added to the `.github/workflows` directory of your repository.
|
||||
{% endif %}
|
||||
|
||||
## Specifying a Swift version
|
||||
|
||||
To use a specific preinstalled version of Swift on a {% data variables.product.prodname_dotcom %}-hosted runner, use the `swift-actions/setup-swift` action. This action finds a specific version of Swift from the tools cache on the runner and adds the necessary binaries to `PATH`. These changes will persist for the remainder of a job. For more information, see the [`swift-actions/setup-swift`](https://github.com/marketplace/actions/setup-swift) action.
|
||||
|
||||
@@ -94,6 +94,7 @@ Before you begin, you'll create a repository on {% ifversion ghae %}{% data vari
|
||||
- run: goodbye.sh
|
||||
shell: bash
|
||||
```
|
||||
|
||||
{% endraw %}
|
||||
This file defines the `who-to-greet` input, maps the random generated number to the `random-number` output variable, adds the action's path to the runner system path (to locate the `goodbye.sh` script during execution), and runs the `goodbye.sh` script.
|
||||
|
||||
|
||||
@@ -107,6 +107,7 @@ Next, the script gets the current time and sets it as an output variable that ac
|
||||
{%- else %}
|
||||
echo "::set-output name=time::$time"
|
||||
{%- endif %}
|
||||
|
||||
```
|
||||
|
||||
If `entrypoint.sh` executes without any errors, the action's status is set to `success`. You can also explicitly set exit codes in your action's code to provide an action's status. For more information, see "[AUTOTITLE](/actions/creating-actions/setting-exit-codes-for-actions)."
|
||||
@@ -114,8 +115,8 @@ Next, the script gets the current time and sets it as an output variable that ac
|
||||
1. Make your `entrypoint.sh` file executable. Git provides a way to explicitly change the permission mode of a file so that it doesn’t get reset every time there is a clone/fork.
|
||||
|
||||
```shell copy
|
||||
$ git add entrypoint.sh
|
||||
$ git update-index --chmod=+x entrypoint.sh
|
||||
git add entrypoint.sh
|
||||
git update-index --chmod=+x entrypoint.sh
|
||||
```
|
||||
|
||||
1. Optionally, to check the permission mode of the file in the git index, run the following command.
|
||||
@@ -266,6 +267,7 @@ jobs:
|
||||
name: workspace_artifacts
|
||||
path: {% raw %}${{ github.workspace }}{% endraw %}
|
||||
```
|
||||
|
||||
For more information about uploading build output as an artifact, see "[AUTOTITLE](/actions/using-workflows/storing-workflow-data-as-artifacts)."
|
||||
|
||||
## Example Docker container actions on {% data variables.product.prodname_dotcom_the_website %}
|
||||
|
||||
@@ -36,7 +36,7 @@ Once you complete this project, you should understand how to build your own Java
|
||||
|
||||
Before you begin, you'll need to download Node.js and create a public {% data variables.product.prodname_dotcom %} repository.
|
||||
|
||||
1. Download and install Node.js 16.x, which includes npm.
|
||||
1. Download and install Node.js 20.x, which includes npm.
|
||||
|
||||
https://nodejs.org/en/download/
|
||||
1. Create a new public repository on {% data variables.location.product_location %} and call it "hello-world-javascript-action". For more information, see "[AUTOTITLE](/repositories/creating-and-managing-repositories/creating-a-new-repository)."
|
||||
@@ -71,7 +71,7 @@ outputs:
|
||||
time: # id of output
|
||||
description: 'The time we greeted you'
|
||||
runs:
|
||||
using: 'node16'
|
||||
using: 'node20'
|
||||
main: 'index.js'
|
||||
```
|
||||
|
||||
|
||||
@@ -157,11 +157,11 @@ For more information on how to use context syntax, see "[AUTOTITLE](/actions/lea
|
||||
|
||||
**Required** Configures the path to the action's code and the runtime used to execute the code.
|
||||
|
||||
### Example: Using Node.js v16
|
||||
### Example: Using Node.js v20
|
||||
|
||||
```yaml
|
||||
runs:
|
||||
using: 'node16'
|
||||
using: 'node20'
|
||||
main: 'main.js'
|
||||
```
|
||||
|
||||
@@ -169,7 +169,7 @@ runs:
|
||||
|
||||
**Required** The runtime used to execute the code specified in [`main`](#runsmain).
|
||||
|
||||
- Use `node16` for Node.js v16.
|
||||
- Use `node20` for Node.js v20.
|
||||
|
||||
### `runs.main`
|
||||
|
||||
@@ -183,7 +183,7 @@ In this example, the `pre:` action runs a script called `setup.js`:
|
||||
|
||||
```yaml
|
||||
runs:
|
||||
using: 'node16'
|
||||
using: 'node20'
|
||||
pre: 'setup.js'
|
||||
main: 'index.js'
|
||||
post: 'cleanup.js'
|
||||
@@ -210,7 +210,7 @@ In this example, the `post:` action runs a script called `cleanup.js`:
|
||||
|
||||
```yaml
|
||||
runs:
|
||||
using: 'node16'
|
||||
using: 'node20'
|
||||
main: 'index.js'
|
||||
post: 'cleanup.js'
|
||||
```
|
||||
|
||||
@@ -52,7 +52,7 @@ To configure the role and trust in IAM, see the AWS documentation "[Configure AW
|
||||
|
||||
{% endnote %}
|
||||
|
||||
Edit the trust policy to add the `sub` field to the validation conditions. For example:
|
||||
Edit the trust policy, adding the `sub` field to the validation conditions. For example:
|
||||
|
||||
```json copy
|
||||
"Condition": {
|
||||
@@ -63,6 +63,17 @@ Edit the trust policy to add the `sub` field to the validation conditions. For e
|
||||
}
|
||||
```
|
||||
|
||||
If you use a workflow with an environment, the `sub` field must reference the environment name: `repo:OWNER/REPOSITORY:environment:NAME`. For more information, see "[AUTOTITLE](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#understanding-the-oidc-token)."
|
||||
|
||||
```json{:copy}
|
||||
"Condition": {
|
||||
"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:environment:prod"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
In the following example, `StringLike` is used with a wildcard operator (`*`) to allow any branch, pull request merge branch, or environment from the `octo-org/octo-repo` organization and repository to assume a role in AWS.
|
||||
|
||||
```json copy
|
||||
|
||||
@@ -45,6 +45,7 @@ topics:
|
||||
| Running tests on the runner | `npm test`|
|
||||
|
||||
## Example workflow
|
||||
|
||||
The following workflow was created by the {% data variables.product.prodname_dotcom %} Docs Engineering team. The workflow runs tests against the code in a pull request. To review the latest version of this file in the [`github/docs`](https://github.com/github/docs) repository, see [`test.yml`](https://github.com/github/docs/blob/main/.github/workflows/test.yml).
|
||||
|
||||
```yaml annotate copy
|
||||
|
||||
@@ -18,7 +18,7 @@ includeGuides:
|
||||
- /actions/quickstart
|
||||
- /actions/learn-github-actions/understanding-github-actions
|
||||
- /actions/creating-actions/creating-a-docker-container-action
|
||||
- /actions/using-workflows/using-starter-workflows
|
||||
- /actions/learn-github-actions/using-starter-workflows
|
||||
- /actions/automating-builds-and-tests/building-and-testing-python
|
||||
- /actions/automating-builds-and-tests/building-and-testing-nodejs
|
||||
- /actions/publishing-packages/about-packaging-with-github-actions
|
||||
|
||||
@@ -46,6 +46,7 @@ type: tutorial
|
||||
{% endif %}
|
||||
|
||||
{% ifversion ghec or ghes or ghae %}
|
||||
|
||||
## Changing which organizations can access a runner group
|
||||
|
||||
{%- ifversion fpt or ghec or ghes %}
|
||||
@@ -110,12 +111,14 @@ You can edit the name of your runner groups at the enterprise and organization l
|
||||
- [Changing the name of an enterprise runner group](#changing-the-name-of-an-enterprise-runner-group)
|
||||
|
||||
### Changing the name of an organization runner group
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% data reusables.actions.runner-groups-org-navigation %}
|
||||
{% data reusables.actions.changing-the-name-of-a-runner-group %}
|
||||
|
||||
{% ifversion ghes or ghec or ghae %}
|
||||
|
||||
### Changing the name of an enterprise runner group
|
||||
|
||||
{% data reusables.actions.runner-groups-enterprise-navigation %}
|
||||
@@ -135,6 +138,7 @@ You can edit the name of your runner groups at the enterprise and organization l
|
||||
- [Moving an enterprise runner to a group](#moving-an-enterprise-runner-to-a-group)
|
||||
|
||||
### Moving an organization runner to a group
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% data reusables.organizations.navigate-to-org %}
|
||||
@@ -143,6 +147,7 @@ You can edit the name of your runner groups at the enterprise and organization l
|
||||
{% data reusables.actions.moving-a-runner-to-a-group %}
|
||||
|
||||
{% ifversion ghes or ghec or ghae %}
|
||||
|
||||
### Moving an enterprise runner to a group
|
||||
|
||||
{% data reusables.enterprise-accounts.access-enterprise %}
|
||||
@@ -161,12 +166,14 @@ You can edit the name of your runner groups at the enterprise and organization l
|
||||
- [Removing a runner group from an enterprise](#removing-a-runner-group-from-an-enterprise)
|
||||
|
||||
### Removing a runner group from an organization
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% data reusables.actions.runner-groups-org-navigation %}
|
||||
{% data reusables.actions.removing-a-runner-group %}
|
||||
|
||||
{% ifversion ghes or ghec or ghae %}
|
||||
|
||||
### Removing a runner group from an enterprise
|
||||
|
||||
{% data reusables.actions.runner-groups-enterprise-navigation %}
|
||||
|
||||
@@ -87,12 +87,34 @@ By default, the self-hosted runner application verifies the TLS certificate for
|
||||
|
||||
To disable TLS certification verification in the self-hosted runner application, set the `GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY` environment variable to `1` before configuring and running the self-hosted runner application.
|
||||
|
||||
{% linux %}
|
||||
|
||||
```shell
|
||||
export GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY=1
|
||||
./config.sh --url https://github.com/YOUR-ORG/YOUR-REPO --token
|
||||
./run.sh
|
||||
```
|
||||
|
||||
{% endlinux %}
|
||||
{% mac %}
|
||||
|
||||
```shell
|
||||
export GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY=1
|
||||
./config.sh --url https://github.com/YOUR-ORG/YOUR-REPO --token
|
||||
./run.sh
|
||||
```
|
||||
|
||||
{% endmac %}
|
||||
{% windows %}
|
||||
|
||||
```powershell
|
||||
[Environment]::SetEnvironmentVariable('GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY', '1')
|
||||
./config.cmd --url https://github.com/YOUR-ORG/YOUR-REPO --token
|
||||
./run.sh
|
||||
```
|
||||
|
||||
{% endwindows %}
|
||||
|
||||
{% warning %}
|
||||
|
||||
**Warning**: Disabling TLS verification is not recommended since TLS provides privacy and data integrity between the self-hosted runner application and {% data variables.product.product_name %}. We recommend that you install the {% data variables.product.product_name %} certificate in the operating system certificate store for your self-hosted runner. For guidance on how to install the {% data variables.product.product_name %} certificate, check with your operating system vendor.
|
||||
|
||||
@@ -37,6 +37,7 @@ You can create custom labels for runners at the repository{% ifversion ghec or g
|
||||
{% data reusables.actions.self-hosted-runners-create-label-steps %}
|
||||
|
||||
{% ifversion ghec or ghes or ghae %}
|
||||
|
||||
### Creating a custom label for an enterprise runner
|
||||
|
||||
{% data reusables.enterprise-accounts.access-enterprise %}
|
||||
@@ -46,6 +47,7 @@ You can create custom labels for runners at the repository{% ifversion ghec or g
|
||||
{% data reusables.actions.self-hosted-runners-create-label-steps %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Assigning a label to a self-hosted runner
|
||||
|
||||
You can assign labels to self-hosted runners at the repository{% ifversion ghec or ghes or ghae %}, organization, and enterprise{% else %} and organization{% endif %} levels.
|
||||
@@ -65,6 +67,7 @@ You can assign labels to self-hosted runners at the repository{% ifversion ghec
|
||||
{% data reusables.actions.self-hosted-runner-assign-label-steps %}
|
||||
|
||||
{% ifversion ghec or ghes or ghae %}
|
||||
|
||||
### Assigning a label to an enterprise runner
|
||||
|
||||
{% data reusables.enterprise-accounts.access-enterprise %}
|
||||
@@ -75,6 +78,7 @@ You can assign labels to self-hosted runners at the repository{% ifversion ghec
|
||||
{% data reusables.actions.self-hosted-runner-assign-label-steps %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Removing a custom label from a self-hosted runner
|
||||
|
||||
You can remove custom labels from self-hosted runners at the repository{% ifversion ghec or ghes or ghae %}, organization, and enterprise{% else %} and organization{% endif %} levels.
|
||||
@@ -94,6 +98,7 @@ You can remove custom labels from self-hosted runners at the repository{% ifvers
|
||||
{% data reusables.actions.self-hosted-runner-remove-label-steps %}
|
||||
|
||||
{% ifversion ghec or ghes or ghae %}
|
||||
|
||||
### Removing a custom label from an enterprise runner
|
||||
|
||||
{% data reusables.enterprise-accounts.access-enterprise %}
|
||||
|
||||
@@ -14,7 +14,7 @@ featuredLinks:
|
||||
- /actions/publishing-packages/about-packaging-with-github-actions
|
||||
- /actions/monitoring-and-troubleshooting-workflows/about-monitoring-and-troubleshooting
|
||||
guideCards:
|
||||
- /actions/using-workflows/using-starter-workflows
|
||||
- /actions/learn-github-actions/using-starter-workflows
|
||||
- /actions/publishing-packages/publishing-nodejs-packages
|
||||
- /actions/automating-builds-and-tests/building-and-testing-powershell
|
||||
popular:
|
||||
|
||||
@@ -25,6 +25,7 @@ children:
|
||||
- /expressions
|
||||
- /contexts
|
||||
- /variables
|
||||
- /using-starter-workflows
|
||||
- /usage-limits-billing-and-administration
|
||||
---
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ redirect_from:
|
||||
- /actions/building-and-testing-code-with-continuous-integration/setting-up-continuous-integration-using-github-actions
|
||||
- /actions/guides/setting-up-continuous-integration-using-workflow-templates
|
||||
- /actions/learn-github-actions/using-workflow-templates
|
||||
- /actions/learn-github-actions/using-starter-workflows
|
||||
- /actions/using-workflows/using-starter-workflows
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
@@ -26,21 +26,24 @@ topics:
|
||||
|
||||
## About starter workflows
|
||||
|
||||
{% data variables.product.product_name %} offers starter workflows for a variety of languages and tooling. When you set up workflows in your repository, {% data variables.product.product_name %} analyzes the code in your repository and recommends workflows based on the language and framework in your repository. For example, if you use [Node.js](https://nodejs.org/en/), {% data variables.product.product_name %} will suggest a starter workflow file that installs your Node.js packages and runs your tests.{% ifversion actions-starter-template-ui %} You can search and filter to find relevant starter workflows.{% endif %}
|
||||
Starter workflows are templates that help you to create your own {% data variables.product.prodname_actions %} workflows for a repository. They offer an alternative to starting from a blank workflow file and are useful because some of the work will already have been done for you.
|
||||
|
||||
{% data variables.product.product_name %} offers starter workflows for a variety of languages and tooling. When you set up workflows in your repository, {% data variables.product.product_name %} analyzes the code in your repository and recommends workflows based on the language and framework in your repository. For example, if you use Node.js, {% data variables.product.product_name %} will suggest a starter workflow file that installs your Node.js packages and runs your tests.{% ifversion actions-starter-template-ui %} You can search and filter to find relevant starter workflows.{% endif %}
|
||||
|
||||
{% data reusables.actions.starter-workflow-categories %}
|
||||
|
||||
You can also create your own starter workflow to share with your organization. These starter workflows will appear alongside the {% data variables.product.product_name %}-provided starter workflows. For more information, see "[AUTOTITLE](/actions/using-workflows/creating-starter-workflows-for-your-organization)."
|
||||
You can also create your own starter workflow to share with your organization. These starter workflows will appear alongside the {% data variables.product.product_name %}-provided starter workflows. Anyone with write access to the organization's `github` repository can set up a starter workflow. For more information, see "[AUTOTITLE](/actions/using-workflows/creating-starter-workflows-for-your-organization)."
|
||||
|
||||
## Using starter workflows
|
||||
|
||||
Anyone with write permission to a repository can set up {% data variables.product.prodname_actions %} starter workflows for CI/CD or other automation.
|
||||
## Choosing and using a starter workflow
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
1. If you already have a workflow in your repository, click **New workflow**.
|
||||
{% data reusables.actions.new-starter-workflow %}
|
||||
1. The "{% ifversion actions-starter-template-ui %}Choose a workflow{% else %}Choose a workflow template{% endif %}" page shows a selection of recommended starter workflows. Find the starter workflow that you want to use, then click {% ifversion actions-starter-template-ui %}**Configure**{% else %}**Set up this workflow**{% endif %}.{% ifversion actions-starter-template-ui %} To help you find the starter workflow that you want, you can search for keywords or filter by category.{% endif %}
|
||||
1. If the starter workflow contains comments detailing additional setup steps, follow these steps. Many of the starter workflow have corresponding guides. For more information, see the [{% data variables.product.prodname_actions %} guides](/actions/guides).
|
||||
1. If the starter workflow contains comments detailing additional setup steps, follow these steps.
|
||||
|
||||
There are guides to accompany many of the starter workflows for building and testing projects. For more information, see "[AUTOTITLE](/actions/automating-builds-and-tests)."
|
||||
|
||||
1. Some starter workflows use secrets. For example, {% raw %}`${{ secrets.npm_token }}`{% endraw %}. If the starter workflow uses a secret, store the value described in the secret name as a secret in your repository. For more information, see "[AUTOTITLE](/actions/security-guides/using-secrets-in-github-actions)."
|
||||
1. Optionally, make additional changes. For example, you might want to change the value of `on` to change when the workflow runs.
|
||||
1. Click **Start commit**.
|
||||
@@ -51,7 +54,6 @@ Anyone with write permission to a repository can set up {% data variables.produc
|
||||
- "[AUTOTITLE](/actions/automating-builds-and-tests/about-continuous-integration)"
|
||||
- "[AUTOTITLE](/actions/managing-workflow-runs)"
|
||||
- "[AUTOTITLE](/actions/monitoring-and-troubleshooting-workflows/about-monitoring-and-troubleshooting)"
|
||||
- "[AUTOTITLE](/actions/learn-github-actions)"
|
||||
{% ifversion fpt or ghec %}
|
||||
- "[AUTOTITLE](/billing/managing-billing-for-github-actions)"
|
||||
{% endif %}
|
||||
@@ -184,6 +184,7 @@ To perform a dry run of migrating a Bitbucket pipeline to {% data variables.prod
|
||||
```bash
|
||||
gh actions-importer dry-run bitbucket --workspace :workspace --repository :repo --output-dir tmp/dry-run
|
||||
```
|
||||
|
||||
### Inspecting the converted workflows
|
||||
|
||||
You can view the logs of the dry run and the converted workflow files in the specified output directory.
|
||||
@@ -205,6 +206,7 @@ To migrate a Bitbucket pipeline to {% data variables.product.prodname_actions %}
|
||||
```bash
|
||||
gh actions-importer migrate bitbucket --workspace :workspace --repository :repo --target-url https://github.com/:owner/:repo --output-dir tmp/dry-run
|
||||
```
|
||||
|
||||
The command's output includes the URL of the pull request that adds the converted workflow to your repository. An example of a successful output is similar to the following:
|
||||
|
||||
```bash
|
||||
|
||||
@@ -73,7 +73,7 @@ jobs:
|
||||
# Setup .npmrc file to publish to npm
|
||||
- uses: {% data reusables.actions.action-setup-node %}
|
||||
with:
|
||||
node-version: '16.x'
|
||||
node-version: '20.x'
|
||||
registry-url: 'https://registry.npmjs.org'
|
||||
- run: npm ci
|
||||
- run: npm publish
|
||||
@@ -136,7 +136,7 @@ jobs:
|
||||
# Setup .npmrc file to publish to GitHub Packages
|
||||
- uses: {% data reusables.actions.action-setup-node %}
|
||||
with:
|
||||
node-version: '16.x'
|
||||
node-version: '20.x'
|
||||
registry-url: 'https://npm.pkg.github.com'
|
||||
# Defaults to the user or organization that owns the workflow file
|
||||
scope: '@octocat'
|
||||
@@ -171,7 +171,7 @@ jobs:
|
||||
# Setup .npmrc file to publish to npm
|
||||
- uses: {% data reusables.actions.action-setup-node %}
|
||||
with:
|
||||
node-version: '16.x'
|
||||
node-version: 20.x'
|
||||
registry-url: 'https://registry.npmjs.org'
|
||||
# Defaults to the user or organization that owns the workflow file
|
||||
scope: '@octocat'
|
||||
|
||||
@@ -50,6 +50,7 @@ For example, the following diagram has a runner group named `grp-ubuntu-20.04-16
|
||||
{% data reusables.actions.section-using-unique-names-for-runner-groups %}
|
||||
|
||||
{% ifversion ghec %}
|
||||
|
||||
## Changing which organizations can access a runner group
|
||||
|
||||
{% data reusables.actions.hosted-runner-security-admonition %}
|
||||
@@ -112,12 +113,14 @@ You can rename runner groups at the enterprise and organization levels.
|
||||
- [Changing the name of an enterprise runner group](##changing-the-name-of-an-enterprise-runner-group)
|
||||
|
||||
### Changing the name of an organization runner group
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% data reusables.actions.runner-groups-org-navigation %}
|
||||
{% data reusables.actions.changing-the-name-of-a-runner-group %}
|
||||
|
||||
{% ifversion ghec %}
|
||||
|
||||
### Changing the name of an enterprise runner group
|
||||
|
||||
{% data reusables.actions.runner-groups-enterprise-navigation %}
|
||||
@@ -133,6 +136,7 @@ You can rename runner groups at the enterprise and organization levels.
|
||||
- [Moving an enterprise runner to a group](#moving-an-enterprise-runner-to-a-group)
|
||||
|
||||
### Moving an organization runner to a group
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% data reusables.organizations.navigate-to-org %}
|
||||
@@ -141,6 +145,7 @@ You can rename runner groups at the enterprise and organization levels.
|
||||
{% data reusables.actions.moving-a-runner-to-a-group %}
|
||||
|
||||
{% ifversion ghec %}
|
||||
|
||||
### Moving an enterprise runner to a group
|
||||
|
||||
{% data reusables.enterprise-accounts.access-enterprise %}
|
||||
@@ -159,12 +164,14 @@ You can rename runner groups at the enterprise and organization levels.
|
||||
- [Removing a runner group from an enterprise](#removing-a-runner-group-from-an-enterprise)
|
||||
|
||||
### Removing a runner group from an organization
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% data reusables.actions.runner-groups-org-navigation %}
|
||||
{% data reusables.actions.removing-a-runner-group %}
|
||||
|
||||
{% ifversion ghec %}
|
||||
|
||||
### Removing a runner group from an enterprise
|
||||
|
||||
{% data reusables.actions.runner-groups-enterprise-navigation %}
|
||||
|
||||
@@ -10,6 +10,7 @@ redirect_from:
|
||||
---
|
||||
|
||||
{% ifversion ghec %}
|
||||
|
||||
## Adding a {% data variables.actions.hosted_runner %} to an enterprise
|
||||
|
||||
Enterprise owners can add {% data variables.actions.hosted_runner %}s to an enterprise and assign them to organizations. By default, when a {% data variables.actions.hosted_runner %} is created for an enterprise, it is added to a default runner group that all organizations in the enterprise have access to. While all organizations are granted access to the runner, the repositories in each organization **are not** granted access. For each organization, an organization owner must configure the runner group to specify which repositories have access to the enterprise runner. For more information, see "[Allowing repositories to access a runner group](#allowing-repositories-to-access-a-runner-group)."
|
||||
@@ -69,6 +70,7 @@ You can edit the name of your {% data variables.actions.hosted_runner %}s.
|
||||
- [Changing the name of an enterprise runner](#changing-the-name-of-an-enterprise-runner)
|
||||
|
||||
### Changing the name of an organization runner
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% data reusables.organizations.navigate-to-org %}
|
||||
@@ -78,6 +80,7 @@ You can edit the name of your {% data variables.actions.hosted_runner %}s.
|
||||
{% data reusables.actions.rename-larger-runner %}
|
||||
|
||||
{% ifversion ghec %}
|
||||
|
||||
### Changing the name of an enterprise runner
|
||||
|
||||
{% data reusables.enterprise-accounts.access-enterprise %}
|
||||
@@ -95,7 +98,9 @@ You can control the maximum number of jobs allowed to run concurrently for speci
|
||||
{% ifversion ghec %}
|
||||
- [Configuring autoscaling for an organization runner](#configuring-autoscaling-for-an-organization-runner)
|
||||
- [Configuring autoscaling for an enterprise runner](#configuring-autoscaling-for-an-enterprise-runner)
|
||||
|
||||
### Configuring autoscaling for an organization runner
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% data reusables.organizations.navigate-to-org %}
|
||||
@@ -105,6 +110,7 @@ You can control the maximum number of jobs allowed to run concurrently for speci
|
||||
{% data reusables.actions.configure-autoscaling-for-larger-runners %}
|
||||
|
||||
{% ifversion ghec %}
|
||||
|
||||
### Configuring autoscaling for an enterprise runner
|
||||
|
||||
{% data reusables.enterprise-accounts.access-enterprise %}
|
||||
@@ -133,6 +139,7 @@ The number of available IP addresses in the assigned ranges does not restrict nu
|
||||
- [Creating static IP addresses for enterprise runners](#creating-static-ip-addresses-for-enterprise-runners)
|
||||
|
||||
### Creating static IP addresses for organization runners
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% data reusables.organizations.navigate-to-org %}
|
||||
@@ -142,6 +149,7 @@ The number of available IP addresses in the assigned ranges does not restrict nu
|
||||
{% data reusables.actions..networking-for-larger-runners %}
|
||||
|
||||
{% ifversion ghec %}
|
||||
|
||||
### Creating static IP addresses for enterprise runners
|
||||
|
||||
{% data reusables.enterprise-accounts.access-enterprise %}
|
||||
|
||||
@@ -50,7 +50,7 @@ For more on managing workflow runs, such as re-running, cancelling, or deleting
|
||||
|
||||
{% data reusables.actions.workflow-template-overview %}
|
||||
|
||||
For more information on using and creating starter workflows, see "[AUTOTITLE](/actions/using-workflows/using-starter-workflows)" and "[AUTOTITLE](/actions/using-workflows/creating-starter-workflows-for-your-organization)."
|
||||
For more information on using and creating starter workflows, see "[AUTOTITLE](/actions/learn-github-actions/using-starter-workflows)" and "[AUTOTITLE](/actions/using-workflows/creating-starter-workflows-for-your-organization)."
|
||||
|
||||
## Advanced workflow features
|
||||
|
||||
|
||||
@@ -114,4 +114,4 @@ To add another starter workflow, add your files to the same `workflow-templates`
|
||||
|
||||
## Next steps
|
||||
|
||||
To continue learning about {% data variables.product.prodname_actions %}, see "[AUTOTITLE](/actions/using-workflows/using-starter-workflows)."
|
||||
To continue learning about {% data variables.product.prodname_actions %}, see "[AUTOTITLE](/actions/learn-github-actions/using-starter-workflows)."
|
||||
|
||||
@@ -33,7 +33,6 @@ children:
|
||||
- /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
|
||||
- /using-github-cli-in-workflows
|
||||
---
|
||||
|
||||
@@ -277,6 +277,7 @@ On an instance in a high-availability configuration, after you restore to new di
|
||||
To remediate after the restoration completes and before starting replication, you can tear down stale UUIDs using `ghe-repl-teardown`. If you need further assistance, contact {% data variables.contact.contact_ent_support %}.
|
||||
|
||||
{% ifversion backup-utilities-progress %}
|
||||
|
||||
## Monitoring backup or restoration progress
|
||||
|
||||
During a backup or restoration operation, you can use the `ghe-backup-progress` utility on your backup host to monitor the operation's progress. The utility prints the progress of each job sequentially.
|
||||
|
||||
@@ -46,24 +46,28 @@ To ensure users can sign into the new target instance, ensure that your environm
|
||||
```shell copy
|
||||
ssh -p 122 admin@HOSTNAME
|
||||
```
|
||||
|
||||
{%- ifversion ghes = 3.7 %}
|
||||
1. To display a list of encryption and decryption keys, run the following command.
|
||||
|
||||
```shell copy
|
||||
ghe-config secrets.github.encrypted-column-keying-material
|
||||
```
|
||||
|
||||
{%- elsif ghes = 3.8 or ghes = 3.9 %}
|
||||
1. To display a list of decryption keys, run the following command.
|
||||
|
||||
```shell copy
|
||||
ghe-config secrets.github.encrypted-column-keying-material
|
||||
```
|
||||
|
||||
1. Copy the output to a safe and temporary location.
|
||||
1. To display a list of encryption keys, run the following command.
|
||||
|
||||
```shell copy
|
||||
ghe-config secrets.github.encrypted-column-current-encryption-key
|
||||
```
|
||||
|
||||
1. Copy the output to a safe and temporary location.
|
||||
{%- endif %}
|
||||
1. SSH into the destination {% data variables.product.product_name %} instance where you restored the backup. Replace HOSTNAME with the actual hostname of your instance.
|
||||
@@ -71,6 +75,7 @@ To ensure users can sign into the new target instance, ensure that your environm
|
||||
```shell copy
|
||||
ssh -p 122 admin@HOSTNAME
|
||||
```
|
||||
|
||||
1. Enable maintenance mode. For more information, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/enabling-and-scheduling-maintenance-mode#enabling-maintenance-mode-immediately-or-scheduling-a-maintenance-window-for-a-later-time)."
|
||||
1. To verify that the destination instance is ready for configuration, run the following {% ifversion ghes = 3.7 %}command{% elsif ghes = 3.8 or ghes = 3.9 %}commands{% endif %}. There should be no output displayed.
|
||||
|
||||
@@ -80,29 +85,34 @@ To ensure users can sign into the new target instance, ensure that your environm
|
||||
ghe-config secrets.github.encrypted-column-current-encryption-key
|
||||
{%- endif %}
|
||||
```
|
||||
|
||||
{%- ifversion ghes = 3.7 %}
|
||||
1. To update the list of keys on the destination instance, run the following command. Replace KEY-LIST with the output from step 1.
|
||||
|
||||
```shell copy
|
||||
ghe-config secrets.github.encrypted-column-keying-material "KEY-LIST"
|
||||
```
|
||||
|
||||
{%- elsif ghes = 3.8 or ghes = 3.9 %}
|
||||
1. To update the decryption keys on the destination instance, run the following command. Replace DECRYPTION-KEY-LIST with the output from step 1.
|
||||
|
||||
```shell copy
|
||||
ghe-config secrets.github.encrypted-column-keying-material "DECRYPTION-KEY-LIST"
|
||||
```
|
||||
|
||||
1. To update the encryption key on the destination instance, run the following command. Replace ENCRYPTION-KEY with the output from step 4.
|
||||
|
||||
```shell copy
|
||||
ghe-config secrets.github.encrypted-column-current-encryption-key "ENCRYPTION-KEY"
|
||||
```
|
||||
|
||||
{%- endif %}
|
||||
1. To apply the configuration, run the following command.
|
||||
|
||||
```shell copy
|
||||
ghe-config-apply
|
||||
```
|
||||
|
||||
1. Wait for the configuration run to complete.
|
||||
1. To ensure that the target instance's configuration contains the keys, run the following {% ifversion ghes = 3.7 %}command{% elsif ghes = 3.8 or ghes = 3.9 %}commands{% endif %} and verify that the output matches step 1{% ifversion ghes = 3.8 or ghes = 3.9 %} and step 4{% endif %}.
|
||||
|
||||
@@ -112,6 +122,7 @@ To ensure users can sign into the new target instance, ensure that your environm
|
||||
ghe-config secrets.github.encrypted-column-current-encryption-key
|
||||
{%- endif %}
|
||||
```
|
||||
|
||||
1. Have a user sign into the destination instance. If any issues arise, contact {% data variables.contact.enterprise_support %}. For more information, see "[AUTOTITLE](/support/contacting-github-support)."
|
||||
|
||||
{% endif %}
|
||||
|
||||
@@ -69,6 +69,7 @@ We do not recommend customizing UFW as it can complicate some troubleshooting is
|
||||
|
||||
1. Configure a custom firewall rule.
|
||||
1. Check the status of each new rule with the `status numbered` command.
|
||||
|
||||
```shell
|
||||
sudo ufw status numbered
|
||||
```
|
||||
|
||||
@@ -107,6 +107,7 @@ Optionally, organization owners can further restrict the access policy of the ru
|
||||
For more information, see "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/managing-access-to-self-hosted-runners-using-groups#changing-the-access-policy-of-a-self-hosted-runner-group)."
|
||||
|
||||
## 5. Automatically scale your self-hosted runners
|
||||
|
||||
{% ifversion actions-runner-controller %}Optionally, you can use {% data variables.product.prodname_actions_runner_controller %} (ARC) to automatically scale self-hosted runners. {% data reusables.actions.actions-runner-controller-about-arc %}
|
||||
|
||||
{% else %}Optionally, you can build custom tooling to automatically scale the self-hosted runners for {% ifversion ghec or ghae %}your enterprise{% elsif ghes %}{% data variables.location.product_location %}{% endif %}. For example, your tooling can respond to webhook events from {% data variables.location.product_location %} to automatically scale a cluster of runner machines. For more information, see "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/autoscaling-with-self-hosted-runners)."
|
||||
|
||||
@@ -36,4 +36,5 @@ If you enable the collection of data about {% data variables.product.prodname_ac
|
||||
```shell{:copy}
|
||||
ghe-config app.github.enable-actions-usage-stats true
|
||||
```
|
||||
|
||||
{% data reusables.enterprise.apply-configuration %}
|
||||
|
||||
@@ -55,6 +55,7 @@ Then, when told to fetch `https://github.example.com/myorg/myrepo`, Git will ins
|
||||
```
|
||||
ghe-repl-setup -a PRIMARY-IP
|
||||
```
|
||||
|
||||
1. To configure the repository cache, use the `ghe-repl-node` command and include the necessary parameters.
|
||||
- Set a `cache-location` for the repository cache, replacing _CACHE-LOCATION_ with an alphanumeric identifier, such as the region where the cache is deployed. The _CACHE-LOCATION_ value must not be any of the subdomains reserved for use with subdomain isolation, such as `assets` or `media`. For a list of reserved names, see "[AUTOTITLE](/admin/configuration/configuring-network-settings/enabling-subdomain-isolation#about-subdomain-isolation)."
|
||||
- Set a `cache-domain` for the repository cache, replacing _EXTERNAL-CACHE-DOMAIN_ with the hostname Git clients will use to access the repository cache. If you do not specify a `cache-domain`, {% data variables.product.product_name %} will prepend the _CACHE-LOCATION_ value as a subdomain to the hostname configured for your instance. For more information, see "[AUTOTITLE](/admin/configuration/configuring-network-settings/configuring-a-hostname)."
|
||||
|
||||
@@ -100,6 +100,7 @@ This example configuration uses a primary and two replicas, which are located in
|
||||
```
|
||||
|
||||
1. To apply the configuration, use the `ghe-config-apply` command on the primary.
|
||||
|
||||
```shell
|
||||
(primary)$ ghe-config-apply
|
||||
```
|
||||
|
||||
@@ -133,16 +133,19 @@ If you cannot upgrade {% data variables.location.product_location %}, then you c
|
||||
```shell copy
|
||||
ghe-maintenance -s
|
||||
```
|
||||
|
||||
1. Update consul template for nomad:
|
||||
|
||||
```shell copy
|
||||
sudo sed -i.bak '/kill_signal/i \ kill_timeout = "10m"' /etc/consul-templates/etc/nomad-jobs/mysql/mysql.hcl.ctmpl
|
||||
```
|
||||
|
||||
1. Render consul template for nomad:
|
||||
|
||||
```shell copy
|
||||
sudo consul-template -once -template /etc/consul-templates/etc/nomad-jobs/mysql/mysql.hcl.ctmpl:/etc/nomad-jobs/mysql/mysql.hcl
|
||||
```
|
||||
|
||||
1. Verify current `kill_timeout` setting:
|
||||
|
||||
```shell copy
|
||||
@@ -154,26 +157,31 @@ If you cannot upgrade {% data variables.location.product_location %}, then you c
|
||||
```shell copy
|
||||
"KillTimeout": 5000000000
|
||||
```
|
||||
|
||||
1. Stop MySQL:
|
||||
|
||||
```shell copy
|
||||
nomad job stop mysql
|
||||
```
|
||||
|
||||
1. Run new MySQL job:
|
||||
|
||||
```shell copy
|
||||
nomad job run /etc/nomad-jobs/mysql/mysql.hcl
|
||||
```
|
||||
|
||||
1. Verify kill_timeout has been updated:
|
||||
|
||||
```shell copy
|
||||
nomad job inspect mysql | grep KillTimeout
|
||||
```
|
||||
|
||||
Expected response:
|
||||
|
||||
```shell copy
|
||||
"KillTimeout": 600000000000,
|
||||
```
|
||||
|
||||
1. Take instance out of maintenance mode:
|
||||
|
||||
```shell copy
|
||||
|
||||
@@ -41,7 +41,7 @@ You can choose to disable {% data variables.product.prodname_actions %} for all
|
||||
{% data reusables.enterprise-accounts.actions-tab %}
|
||||
1. Under "Policies", select your options.
|
||||
|
||||
{% indented_data_reference reusables.actions.actions-use-policy-settings spaces=3 %}
|
||||
{% data reusables.actions.actions-use-policy-settings %}
|
||||
|
||||
{%- ifversion ghes or ghae %}
|
||||
{% note %}
|
||||
|
||||
@@ -81,6 +81,7 @@ The following sections will lead you through setting up the following components
|
||||
1. Create a Ruby file named `server.rb`. This file will contain all the code for your app. You will add content to this file later.
|
||||
1. If the directory doesn't already include a `.gitignore` file, add a `.gitignore` file. You will add content to this file later. For more information about `.gitignore` files, see "[AUTOTITLE](/get-started/getting-started-with-git/ignoring-files)."
|
||||
1. Create a file named `Gemfile`. This file will describe the gem dependencies that your Ruby code needs. Add the following contents to your `Gemfile`:
|
||||
|
||||
```ruby copy
|
||||
source 'http://rubygems.org'
|
||||
|
||||
@@ -92,7 +93,9 @@ The following sections will lead you through setting up the following components
|
||||
gem 'dotenv'
|
||||
gem 'git'
|
||||
```
|
||||
|
||||
1. Create a file named `config.ru`. This file will configure your Sinatra server to run. Add the following contents to your `config.ru` file:
|
||||
|
||||
```ruby copy
|
||||
require './server'
|
||||
run GHAapp
|
||||
@@ -103,17 +106,22 @@ The following sections will lead you through setting up the following components
|
||||
In order to develop your app locally, you can use a webhook proxy URL to forward webhook events from {% data variables.product.company_short %} to your computer or codespace. This tutorial uses Smee.io to provide a webhook proxy URL and forward events.
|
||||
|
||||
1. In a terminal, run the following command to install the Smee client:
|
||||
|
||||
```shell copy
|
||||
npm install --global smee-client
|
||||
```
|
||||
|
||||
1. In your browser, navigate to https://smee.io/.
|
||||
1. Click **Start a new channel**.
|
||||
1. Copy the full URL under "Webhook Proxy URL".
|
||||
1. In the terminal, run the following command to start the Smee client. Replace `YOUR_DOMAIN` with the Webhook Proxy URL you copied in the previous step.
|
||||
|
||||
```shell copy
|
||||
smee --url YOUR_DOMAIN --path /event_handler --port 3000
|
||||
```
|
||||
|
||||
You should see output like the following:
|
||||
|
||||
```shell
|
||||
Forwarding https://smee.io/YOUR_DOMAIN to http://127.0.0.1:3000/event_handler
|
||||
Connected https://smee.io/YOUR_DOMAIN
|
||||
|
||||
@@ -31,5 +31,6 @@ Some authenticators allow passkeys to be used with nearby devices. For example,
|
||||
1. On your nearby device, follow the prompts to complete the authentication process. For example, if you are using an iPhone, you might perform FaceID or enter your passcode.
|
||||
|
||||
## Further reading
|
||||
|
||||
- [AUTOTITLE](/authentication/authenticating-with-a-passkey/about-passkeys)
|
||||
- [AUTOTITLE](/authentication/authenticating-with-a-passkey/managing-your-passkeys)
|
||||
|
||||
@@ -63,6 +63,7 @@ To confirm access for sudo mode, you {% ifversion totp-and-mobile-sudo-challenge
|
||||
{%- endif %}
|
||||
|
||||
{% ifversion passkeys %}
|
||||
|
||||
## Confirming access using a passkey
|
||||
|
||||
You must have a passkey registered to your account to confirm access to your account for sudo mode using a passkey. For more information, see "[AUTOTITLE](/authentication/authenticating-with-a-passkey/about-passkeys)" and "[AUTOTITLE](/authentication/authenticating-with-a-passkey/managing-your-passkeys)."
|
||||
|
||||
@@ -51,6 +51,7 @@ If you've set up a security key on your account, and your browser supports secur
|
||||
1. Select the appropriate option in the prompt. Depending on your security key configuration, you may type a PIN, complete a biometric prompt, or use a physical security key.
|
||||
|
||||
{% ifversion passkeys %}
|
||||
|
||||
### Using a passkey
|
||||
|
||||
If you have enabled 2FA, and you have added a passkey to your account, you can use the passkey to sign in. Since passkeys satisfy both password and 2FA requirements, you can complete your sign in with a single step. For more information, see "[AUTOTITLE](/authentication/authenticating-with-a-passkey/about-passkeys)" and "[AUTOTITLE](/authentication/authenticating-with-a-passkey/signing-in-with-a-passkey)."
|
||||
|
||||
@@ -78,7 +78,7 @@ $ ssh -T git@{% data variables.command_line.codeblock %}
|
||||
|
||||
{% data reusables.desktop.windows_git_for_windows_turn_on_ssh_agent %}
|
||||
|
||||
{% indented_data_reference reusables.desktop.note-start-ssh-agent spaces=3 %}
|
||||
{% data reusables.desktop.note-start-ssh-agent %}
|
||||
|
||||
1. Verify that you have a private key generated and loaded into SSH.
|
||||
|
||||
|
||||
@@ -89,6 +89,7 @@ To reduce the number of paid seats your organization uses, you can remove member
|
||||
1. Review the information about your new payment on your next billing date, then click **Remove seats**.
|
||||
|
||||
{% ifversion ghec %}
|
||||
|
||||
## Downgrading your enterprise account's plan
|
||||
|
||||
Enterprise accounts are only available with {% data variables.product.prodname_enterprise %}, so it's not possible to downgrade an enterprise account to another plan.
|
||||
|
||||
@@ -163,10 +163,11 @@ For information on bulk enablement, see "[AUTOTITLE](/code-security/code-scannin
|
||||
|
||||

|
||||
|
||||
For more information, see "[AUTOTITLE](/actions/using-workflows/using-starter-workflows#using-starter-workflows)" and "[AUTOTITLE](/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/customizing-your-advanced-setup-for-code-scanning)."
|
||||
For more information, see "[AUTOTITLE](/actions/learn-github-actions/using-starter-workflows#choosing-and-using-a-starter-workflow)" and "[AUTOTITLE](/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/customizing-your-advanced-setup-for-code-scanning)."
|
||||
|
||||
{% endif %}
|
||||
{% ifversion ghes < 3.5 %}
|
||||
|
||||
## Reasons for the "Analysis not found" message
|
||||
|
||||
If you used a pull request to add {% data variables.product.prodname_code_scanning %} to the repository, you will initially see an "Analysis not found" message when you click **Details** on the "{% data variables.product.prodname_code_scanning_caps %} results / TOOL NAME" check in a pull request.
|
||||
|
||||
@@ -54,6 +54,7 @@ If the code in a repository changes to include {% ifversion code-scanning-defaul
|
||||
|
||||
{% endif %}
|
||||
{% ifversion org-enable-code-scanning %}
|
||||
|
||||
## Configuring default setup for all eligible repositories in an organization
|
||||
|
||||
Through the "Code security and analysis" page of your organization's settings, you can enable default setup for all eligible repositories in your organization. For more information on repository eligibility, see "[Eligible repositories for {% data variables.product.prodname_codeql %} default setup at scale](#eligible-repositories-default-setup)."
|
||||
@@ -80,6 +81,7 @@ Through the "Code security and analysis" page of your organization's settings, y
|
||||
{% data variables.product.prodname_code_scanning_caps %} is configured at the repository level. For more information, see "[AUTOTITLE](/code-security/code-scanning/enabling-code-scanning/configuring-default-setup-for-code-scanning)."
|
||||
{% endif %}
|
||||
{% ifversion code-security-multi-repo-enablement %}
|
||||
|
||||
## Configuring default setup for a subset of repositories in an organization
|
||||
|
||||
Through security overview for your organization, you can find eligible repositories for default setup, then enable default setup across each of those repositories simultaneously. For more information on repository eligibility, see "[Eligible repositories for {% data variables.product.prodname_codeql %} default setup at scale](#eligible-repositories-default-setup)."
|
||||
|
||||
@@ -26,6 +26,7 @@ If your codebase depends on a library or framework that is not recognized by the
|
||||
If you need to change any other aspects of your {% data variables.product.prodname_code_scanning %} configuration, consider configuring advanced setup. For more information, see "[AUTOTITLE](/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/configuring-advanced-setup-for-code-scanning)."
|
||||
|
||||
{% ifversion code-scanning-without-workflow-310 %}
|
||||
|
||||
## Customizing your existing configuration of default setup
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
@@ -38,6 +39,7 @@ If you need to change any other aspects of your {% data variables.product.prodna
|
||||
1. To update your configuration, as well as run an initial analysis of your code with the new configuration, click **Save changes**. All future analyses will use your new configuration.
|
||||
|
||||
{% else %}
|
||||
|
||||
## Changing the selected query suite for your configuration of default setup
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
|
||||
@@ -18,11 +18,14 @@ versions:
|
||||
On very large projects, you may see `Error: "Out of disk"` or `Error: "Out of memory"` on self-hosted runners when running {% data variables.product.prodname_codeql %}. In this case, you may need to increase the memory or disk space available on your runners. You can review the recommended hardware resources for running {% data variables.product.prodname_codeql %} to make sure your self-hosted runners meet those requirements. For more information, see "[AUTOTITLE](/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/recommended-hardware-resources-for-running-codeql)."
|
||||
|
||||
{% else %}
|
||||
|
||||
## Use self-hosted runners
|
||||
|
||||
Self-hosted runners offer more control of hardware, operating system, and software tools than {% data variables.product.company_short %}-hosted runners can provide. For more information, see "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners)." You can review the recommended hardware resources for running {% data variables.product.prodname_codeql %} to make sure your self-hosted runners meet those requirements. For more information, see "[AUTOTITLE](/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/recommended-hardware-resources-for-running-codeql)."
|
||||
|
||||
{% ifversion actions-hosted-runners %}
|
||||
|
||||
## Use larger runners
|
||||
|
||||
You can use larger runners, which are {% data variables.product.company_short %}-hosted runners with more RAM, CPU, and disk space than standard runners. These runners have the runner application and other tools preinstalled. For more information about larger runners and the specifications you can use with them, see "[AUTOTITLE](/actions/using-github-hosted-runners/about-larger-runners)."{% endif %}
|
||||
{% endif %}
|
||||
|
||||
@@ -80,6 +80,7 @@ codeql database analyze <database> --format=<format> \
|
||||
--sarif-category=<language-specifier> --output=<output> \
|
||||
{% ifversion codeql-packs %}<packs,queries>{% else %}<queries>{% endif %}
|
||||
```
|
||||
|
||||
{% endnote %}
|
||||
|
||||
You must specify `<database>`, `--format`, and `--output`. You can specify additional options depending on what analysis you want to do.
|
||||
@@ -130,6 +131,7 @@ $ codeql database analyze /codeql-dbs/example-repo \
|
||||
```
|
||||
|
||||
{% ifversion code-scanning-tool-status-page %}
|
||||
|
||||
### Adding file coverage information to your results for monitoring
|
||||
|
||||
You can optionally submit file coverage information to {% data variables.product.product_name %} for display on the {% data variables.code-scanning.tool_status_page %} for {% data variables.product.prodname_code_scanning %}. For more information about file coverage information, see "[AUTOTITLE](/code-security/code-scanning/managing-your-code-scanning-configuration/about-the-tool-status-page#how-codeql-defines-scanned-files)."
|
||||
|
||||
@@ -49,6 +49,7 @@ The other files and directories within the pack should be logically organized. F
|
||||
their own top-level directories.
|
||||
|
||||
{% ifversion codeql-packs %}
|
||||
|
||||
## Downloading and using {% data variables.product.prodname_codeql %} query packs
|
||||
|
||||
The {% data variables.product.prodname_codeql_cli %} bundle includes queries that are maintained by {% data variables.product.company_short %} experts, security researchers, and community contributors. If you want to run queries developed by other organizations, {% data variables.product.prodname_codeql %} query packs provide an efficient and reliable way to download and run queries{% ifversion codeql-model-packs-java %}, while model packs (beta) can be used to expand {% data variables.product.prodname_code_scanning %} analysis to recognize libraries and frameworks that are not supported by default{% endif %}. For more information about query packs, see "[AUTOTITLE](/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning-with-codeql#about-codeql-queries)." {% ifversion codeql-model-packs-java %} For information about writing your own model packs, see "[AUTOTITLE](/code-security/codeql-cli/using-the-advanced-functionality-of-the-codeql-cli/creating-and-working-with-codeql-packs#creating-a-model-pack)."{% endif %}
|
||||
@@ -190,6 +191,7 @@ For more information about writing your own model packs, see "[AUTOTITLE](/code-
|
||||
{% endif %}
|
||||
|
||||
{% ifversion query-pack-compatibility %}
|
||||
|
||||
### About published packs
|
||||
|
||||
When a pack is published for use in analyses, the `codeql pack create` or `codeql pack publish` command verifies that the content is complete and also adds some additional pieces of content to it:
|
||||
|
||||
@@ -113,6 +113,7 @@ After you extract the {% data variables.product.prodname_codeql_cli %} bundle, y
|
||||
- `/<extraction-root>/codeql/codeql resolve qlpacks` otherwise.
|
||||
|
||||
Extract from successful output:
|
||||
|
||||
```shell
|
||||
codeql/cpp-all (/<extraction-root>/qlpacks/codeql/cpp-all/<version>)
|
||||
codeql/cpp-examples (/<extraction-root>/qlpacks/codeql/cpp-examples/<version>)
|
||||
|
||||
@@ -76,6 +76,7 @@ codeql github upload-results \
|
||||
There is no output from this command unless the upload was unsuccessful. The command prompt returns when the upload is complete and data processing has begun. On smaller codebases, you should be able to explore the {% data variables.product.prodname_code_scanning %} alerts in {% data variables.product.product_name %} shortly afterward. You can see alerts directly in the pull request or on the **Security** tab for branches, depending on the code you checked out. For more information, see "[AUTOTITLE](/code-security/code-scanning/managing-code-scanning-alerts/triaging-code-scanning-alerts-in-pull-requests)" and "[AUTOTITLE](/code-security/code-scanning/managing-code-scanning-alerts/managing-code-scanning-alerts-for-your-repository)."
|
||||
|
||||
{% ifversion code-scanning-tool-status-page %}
|
||||
|
||||
## Uploading diagnostic information to {% data variables.product.product_name %} if the analysis fails
|
||||
|
||||
When {% data variables.product.prodname_codeql_cli %} finishes analyzing a database successfully, it gathers diagnostic information such as file coverage, warnings, and errors, and includes it in the SARIF file with the results. When you upload the SARIF file to {% data variables.product.company_short %} the diagnostic information is displayed on the {% data variables.product.prodname_code_scanning %} {% data variables.code-scanning.tool_status_page %} for the repository to make it easy to see how well {% data variables.product.prodname_codeql %} is working and debug any problems. For more information, see "[AUTOTITLE](/code-security/code-scanning/managing-your-code-scanning-configuration/about-the-tool-status-page)."
|
||||
|
||||
@@ -34,6 +34,7 @@ default-suite-file: default-queries.qls # optional, a pointer to a query-suite i
|
||||
license: # optional, the license under which the pack is published
|
||||
dependencies: # map from CodeQL pack name to version range
|
||||
```
|
||||
|
||||
- `name:` must follow the `<scope>/<pack>` format, where `<scope>` is the {% data variables.product.prodname_dotcom %} organization that you will publish to and <pack> is the name for the pack.
|
||||
|
||||
- A maximum of one of `default-suite` or `default-suite-file` is allowed. These are two different ways to define a default query suite to be run, the first by specifying queries directly in the qlpack.yml file and the second by specifying a query suite in the pack.
|
||||
@@ -207,6 +208,7 @@ The following properties are supported in `qlpack.yml` files.
|
||||
|
||||
- Required by all packs.
|
||||
- Defines the scope of the pack, where the {% data variables.product.prodname_codeql %} pack is published, and the name of the pack defined using alphanumeric characters and hyphens. It must be unique as {% data variables.product.prodname_codeql %} cannot differentiate between {% data variables.product.prodname_codeql %} packs with identical names. Use the pack name to specify queries to run using `database analyze` and to define dependencies between {% data variables.product.prodname_codeql %} packs (see examples below). For example:
|
||||
|
||||
```yaml
|
||||
name: octo-org/security-queries
|
||||
```
|
||||
@@ -215,11 +217,13 @@ The following properties are supported in `qlpack.yml` files.
|
||||
|
||||
- Required by all packs that are published.
|
||||
- Defines a semantic version for this {% data variables.product.prodname_codeql %} pack that must adhere to the [SemVer v2.0.0 specification](https://semver.org/spec/v2.0.0.html). For example:
|
||||
|
||||
```yaml
|
||||
version: 0.0.0
|
||||
```
|
||||
|
||||
{% ifversion codeql-model-packs-java %}
|
||||
|
||||
#### `dataExtensions`
|
||||
|
||||
- Required by model packs.
|
||||
@@ -230,6 +234,7 @@ The following properties are supported in `qlpack.yml` files.
|
||||
|
||||
- Required by query and library packs that define {% data variables.product.prodname_codeql %} package dependencies on other packs. Model packs cannot define any dependencies and use `extensionTargets` instead.
|
||||
- Defines a map from pack references to the semantic version range that is compatible with this pack. Supported for {% data variables.product.prodname_codeql_cli %} versions v2.6.0 and later. For example:
|
||||
|
||||
```yaml
|
||||
dependencies:
|
||||
codeql/cpp-all: ^0.0.2
|
||||
@@ -239,6 +244,7 @@ The following properties are supported in `qlpack.yml` files.
|
||||
|
||||
- Required by packs that export a set of default queries to run.
|
||||
- Defines the path to a query suite file relative to the package root, containing all of the queries that are run by default when this pack is passed to the `codeql database analyze` command. Supported from CLI version v2.6.0 and onwards. Only one of `defaultSuiteFile` or `defaultSuite` can be defined. For example:
|
||||
|
||||
```yaml
|
||||
defaultSuiteFile: cpp-code-scanning.qls
|
||||
```
|
||||
@@ -247,6 +253,7 @@ The following properties are supported in `qlpack.yml` files.
|
||||
|
||||
- Required by packs that export a set of default queries to run.
|
||||
- Defines an inlined query suite containing all of the queries that are run by default when this pack is passed to the `codeql database analyze` command. Supported from CLI version v2.6.0 and onwards. Only one of `defaultSuiteFile` or `defaultSuite` can be defined. For example:
|
||||
|
||||
```yaml
|
||||
defaultSuite:
|
||||
queries: .
|
||||
@@ -255,6 +262,7 @@ The following properties are supported in `qlpack.yml` files.
|
||||
```
|
||||
|
||||
{% ifversion codeql-model-packs-java %}
|
||||
|
||||
#### `extensionTargets`
|
||||
|
||||
- Required by model packs.
|
||||
@@ -283,6 +291,7 @@ The following properties are supported in `qlpack.yml` files.
|
||||
|
||||
- Required by library packs.
|
||||
- Defines a boolean value that indicates whether or not this pack is a library pack. Library packs do not contain queries and are not compiled. Query packs can ignore this field or explicitly set it to `false`. For example:
|
||||
|
||||
```yaml
|
||||
library: true
|
||||
```
|
||||
@@ -291,68 +300,88 @@ The following properties are supported in `qlpack.yml` files.
|
||||
|
||||
- Optional for packs that define query suites.
|
||||
- Defines the path to a directory in the pack that contains the query suites you want to make known to the {% data variables.product.prodname_codeql_cli %}, defined relative to the pack directory. {% data variables.product.prodname_codeql %} pack users can run "well-known" suites stored in this directory by specifying the pack name, without providing their full path. This is not supported for {% data variables.product.prodname_codeql %} packs downloaded from the Container registry. For more information about query suites, see "[AUTOTITLE](/code-security/codeql-cli/using-the-advanced-functionality-of-the-codeql-cli/creating-codeql-query-suites)." For example:
|
||||
|
||||
```yaml
|
||||
suites: octo-org-query-suites
|
||||
```
|
||||
|
||||
#### `tests`
|
||||
|
||||
- Optional for packs containing {% data variables.product.prodname_codeql %} tests. Ignored for packs without tests.
|
||||
- Defines the path to a directory within the pack that contains tests, defined relative to the pack directory. Use `.` to specify the whole pack. Any queries in this directory are run as tests when `test run` is run with the `--strict-test-discovery` option. These queries are ignored by query suite definitions that use `queries` or `qlpack` instructions to ask for all queries in a particular pack. If this property is missing, then `.` is assumed. For example:
|
||||
|
||||
```yaml
|
||||
tests: .
|
||||
```
|
||||
|
||||
#### `extractor`
|
||||
|
||||
- Required by all packs containing {% data variables.product.prodname_codeql %} tests.
|
||||
- Defines the {% data variables.product.prodname_codeql %} language extractor to use when running the {% data variables.product.prodname_codeql %} tests in the pack. For more information about testing queries, see "[AUTOTITLE](/code-security/codeql-cli/using-the-advanced-functionality-of-the-codeql-cli/testing-custom-queries)." For example:
|
||||
|
||||
```yaml
|
||||
extractor: javascript
|
||||
```
|
||||
|
||||
#### `authors`
|
||||
|
||||
- Optional.
|
||||
- Defines metadata that will be displayed on the packaging search page in the packages section of the account that the {% data variables.product.prodname_codeql %} pack is published to. For example:
|
||||
|
||||
```yaml
|
||||
authors: author1@github.com,author2@github.com
|
||||
```
|
||||
|
||||
#### `license`
|
||||
|
||||
- Optional.
|
||||
- Defines metadata that will be displayed on the packaging search page in the packages section of the account that the {% data variables.product.prodname_codeql %} pack is published to. For a list of allowed licenses, see [SPDX License List](https://spdx.org/licenses/) in the SPDX Specification. For example:
|
||||
|
||||
```yaml
|
||||
license: MIT
|
||||
```
|
||||
|
||||
#### `description`
|
||||
|
||||
- Optional.
|
||||
- Defines metadata that will be displayed on the packaging search page in the packages section of the account that the {% data variables.product.prodname_codeql %} pack is published to. For example:
|
||||
|
||||
```yaml
|
||||
description: Human-readable description of the contents of the {% data variables.product.prodname_codeql %} pack.
|
||||
```
|
||||
|
||||
#### `libraryPathDependencies`
|
||||
|
||||
- Optional, deprecated. Use the `dependencies` property instead.
|
||||
- Previously used to define the names of any {% data variables.product.prodname_codeql %} packs that this {% data variables.product.prodname_codeql %} pack depends on, as an array. This gives the pack access to any libraries, database schema, and query suites defined in the dependency. For example:
|
||||
|
||||
```yaml
|
||||
libraryPathDependencies: codeql/javascript-all
|
||||
```
|
||||
|
||||
#### `dbscheme`
|
||||
|
||||
- Required by core language packs only.
|
||||
- Defines the path to the [database schema](https://codeql.github.com/docs/codeql-overview/codeql-glossary/#codeql-database-schema) for all libraries and queries written for this {% data variables.product.prodname_codeql %} language (see example below). For example:
|
||||
|
||||
```yaml
|
||||
dbscheme: semmlecode.python.dbscheme
|
||||
```
|
||||
|
||||
#### `upgrades`
|
||||
|
||||
- Required by core language packs only.
|
||||
- Defines the path to a directory within the pack that contains database upgrade scripts, defined relative to the pack directory. Database upgrades are used internally to ensure that a database created with a different version of the {% data variables.product.prodname_codeql_cli %} is compatible with the current version of the CLI. For example:
|
||||
|
||||
```yaml
|
||||
upgrades: .
|
||||
```
|
||||
|
||||
#### `warnOnImplicitThis`
|
||||
|
||||
- Optional. Defaults to `false` if the `warnOnImplicitThis` property is not defined.
|
||||
- Defines a boolean that specifies whether or not the compiler should emit warnings about member predicate calls with implicit `this` call receivers, that is, without an explicit receiver. Supported from {% data variables.product.prodname_codeql_cli %} version 2.13.2 and onwards. For example:
|
||||
|
||||
```yaml
|
||||
warnOnImplicitThis: true
|
||||
```
|
||||
|
||||
@@ -144,7 +144,7 @@ other custom queries. For example, `custom-queries/java/queries/EmptyThen.ql`.
|
||||
|
||||
1. Create a {% data variables.product.prodname_codeql %} pack for your Java tests by adding a `qlpack.yml` file with the following contents to `custom-queries/java/tests`, updating the `dependencies` to match the name of your {% data variables.product.prodname_codeql %} pack of custom queries:
|
||||
|
||||
{% indented_data_reference reusables.codeql-cli.test-qlpack spaces=3 %}
|
||||
{% data reusables.codeql-cli.test-qlpack %}
|
||||
|
||||
1. Run `codeql pack install` in the root of the test directory. This generates a `codeql-pack.lock.yml` file that specifies all of the transitive dependencies required to run queries in this pack.
|
||||
|
||||
@@ -232,5 +232,6 @@ into {% data variables.product.prodname_codeql %} for VS Code, execute `EmptyThe
|
||||
`Test.java` example code. For more information, see "[Analyzing your projects](https://codeql.github.com/docs/codeql-for-visual-studio-code/analyzing-your-projects/#analyzing-your-projects)" in the {% data variables.product.prodname_codeql %} for VS Code help.
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[{% data variables.product.prodname_codeql %} queries](https://codeql.github.com/docs/writing-codeql-queries/codeql-queries/#codeql-queries)"
|
||||
- "[Testing {% data variables.product.prodname_codeql %} queries in Visual Studio Code](https://codeql.github.com/docs/codeql-for-visual-studio-code/testing-codeql-queries-in-visual-studio-code/#testing-codeql-queries-in-visual-studio-code)."
|
||||
|
||||
@@ -0,0 +1,46 @@
|
||||
---
|
||||
title: About Dependabot alert rules
|
||||
intro: 'You can use {% data variables.product.prodname_dependabot %} alert rules to auto-triage alerts, so you can reduce false positives and better prioritize the alerts that you''re interested in.'
|
||||
permissions: 'People with write permissions can view {% data variables.product.prodname_dependabot %} alert rules for the repository. People with with admin permissions to a repository, or the security manager role for the repository, can enable or disable {% data variables.product.prodname_dependabot %} alert rules for the repository{% ifversion dependabot-alert-custom-rules-repo-level %}, as well as create custom alert rules{% endif %}.'
|
||||
versions:
|
||||
feature: dependabot-alert-rules-auto-dismissal-npm-dev-dependencies
|
||||
type: overview
|
||||
topics:
|
||||
- Dependabot
|
||||
- Alerts
|
||||
- Vulnerabilities
|
||||
- Repositories
|
||||
- Dependencies
|
||||
shortTitle: About alert rules
|
||||
redirect_from:
|
||||
- /code-security/dependabot/dependabot-alerts/using-alert-rules-to-prioritize-dependabot-alerts
|
||||
---
|
||||
|
||||
{% data reusables.dependabot.github-alert-rules-beta %}
|
||||
|
||||
## About {% data variables.product.prodname_dependabot %} alert rules
|
||||
|
||||
{% data variables.product.prodname_dependabot %} alert rules allow you to instruct {% data variables.product.prodname_dependabot %} to automatically dismiss or reopen certain alerts, based on complex logic from a variety of contextual criteria.
|
||||
|
||||
{% ifversion dependabot-alert-custom-rules-repo-level %}
|
||||
There are two types of {% data variables.product.prodname_dependabot %} alert rules:
|
||||
|
||||
- A {% data variables.product.company_short %}-curated rule, called `Dismiss low impact alerts`
|
||||
- User-created custom rules
|
||||
|
||||
The {% data variables.product.company_short %}-curated rule, `Dismiss low impact alerts`, auto-dismisses certain types of vulnerabilities that are found in npm dependencies used in development. The rule has been curated to reduce false positives and reduce alert fatigue. The rule is enabled by default for public repositories and can be opted into for private repositories. However, you cannot modify {% data variables.product.company_short %}-curated rules. For more information, see "[AUTOTITLE](/code-security/dependabot/dependabot-alert-rules/using-github-curated-alert-rules-to-prioritize-dependabot-alerts)."
|
||||
|
||||
With user-created custom rules, you can create your own rules to automatically dismiss or reopen alerts based on your own criteria, such as severity, package name, CWE, and more. For more information, see "[AUTOTITLE](/code-security/dependabot/dependabot-alert-rules/customizing-alert-rules-to-prioritize-dependabot-alerts)."{% endif %}
|
||||
|
||||
Whilst you may find it useful to auto-dismiss alerts, you can still reopen auto-dismissed alerts and filter to see which alerts have been auto-dismissed. For more information, see "[AUTOTITLE](/code-security/dependabot/dependabot-alert-rules/managing-automatically-dismissed-alerts)."
|
||||
|
||||
Additionally, auto-dismissed alerts are still available for reporting and reviewing, and can be auto-reopened if the alert metadata changes, for example:
|
||||
- If you change the scope of a dependency from development to production.
|
||||
- If {% data variables.product.company_short %} modifies certain metadata for the related advisory.
|
||||
|
||||
Auto-dismissed alerts are defined by the `resolution:auto-dismiss` close reason. Automatic dismissal activity is included in alert webhooks, REST and GraphQL APIs, and the audit log. For more information, see "[AUTOTITLE](/rest/dependabot/alerts)" in the REST API documentation, and the "`repository_vulnerability_alert`" section in "[AUTOTITLE](/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/reviewing-the-audit-log-for-your-organization#repository_vulnerability_alert-category-actions)."
|
||||
|
||||
## Further reading
|
||||
|
||||
- [AUTOTITLE](/code-security/dependabot/dependabot-alert-rules/using-github-curated-alert-rules-to-prioritize-dependabot-alerts)
|
||||
- [AUTOTITLE](/code-security/dependabot/dependabot-alert-rules/customizing-alert-rules-to-prioritize-dependabot-alerts)
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: Customizing alert rules to prioritize Dependabot alerts
|
||||
intro: 'You can create your own alert rules to auto-triage alerts.'
|
||||
permissions: 'People with write permissions can view {% data variables.product.prodname_dependabot %} alert rules for the repository. People with with admin permissions to a repository, or the security manager role for the repository, can enable or disable {% data variables.product.prodname_dependabot %} alert rules for the repository{% ifversion dependabot-alert-custom-rules-repo-level %}, as well as create custom alert rules{% endif %}'
|
||||
product: '{% data reusables.gated-features.dependabot-alert-rules %}'
|
||||
versions:
|
||||
feature: dependabot-alert-rules-auto-dismissal-npm-dev-dependencies
|
||||
type: how_to
|
||||
topics:
|
||||
- Dependabot
|
||||
- Alerts
|
||||
- Vulnerabilities
|
||||
- Repositories
|
||||
- Dependencies
|
||||
shortTitle: Custom alert rules
|
||||
---
|
||||
|
||||
{% data reusables.dependabot.github-alert-rules-beta %}
|
||||
|
||||
## About custom alert rules
|
||||
|
||||
You can create your own {% data variables.product.prodname_dependabot %} alert rules based on alert criteria. You can choose to auto-dismiss alerts indefinitely, or snooze alerts until a patch becomes available. Since any rules that you create apply to both future and current alerts, you can also use alert rules to manage your {% data variables.product.prodname_dependabot_alerts %} in bulk.
|
||||
|
||||
You can create rules using the following criteria:
|
||||
|
||||
- Dependency scope (`devDependency` or `runtime`)
|
||||
- Package name
|
||||
- CWE
|
||||
- Severity
|
||||
- Patch availability
|
||||
- Manifest path
|
||||
- Ecosystem
|
||||
|
||||
## Adding a custom rule to your repository
|
||||
|
||||
You can add a custom rule to your {% ifversion fpt %}public and private{% elsif ghec or ghes %}public, private, and internal{% endif %} repositories.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.repositories.navigate-to-code-security-and-analysis %}
|
||||
1. Under "{% data variables.product.prodname_dependabot_alerts %}", click {% octicon "gear" aria-label="The Gear icon" %} close to "{% data variables.product.prodname_dependabot %} rules".
|
||||
|
||||

|
||||
|
||||
1. Click **New ruleset**.
|
||||
|
||||

|
||||
|
||||
1. Under "Name", describe what this rule will do.
|
||||
1. Under "Alert criteria", select the criteria you want to use to filter alerts.
|
||||
1. Under "Rules", select the action you want to take on alerts that match the criteria.
|
||||
1. Click **Create rule**.
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: Prioritizing Dependabot alerts with Dependabot alert rules
|
||||
shortTitle: Dependabot alert rules
|
||||
intro: 'You can use {% data variables.product.prodname_dependabot %} alert rules to auto-triage {% data variables.product.prodname_dependabot_alerts %}.'
|
||||
allowTitleToDifferFromFilename: true
|
||||
versions:
|
||||
feature: dependabot-alert-rules-auto-dismissal-npm-dev-dependencies
|
||||
topics:
|
||||
- Dependabot
|
||||
- Alerts
|
||||
- Vulnerabilities
|
||||
- Repositories
|
||||
- Dependencies
|
||||
children:
|
||||
- /about-dependabot-alert-rules
|
||||
- /using-github-curated-alert-rules-to-prioritize-dependabot-alerts
|
||||
- /customizing-alert-rules-to-prioritize-dependabot-alerts
|
||||
- /managing-automatically-dismissed-alerts
|
||||
---
|
||||
|
||||
{% data reusables.dependabot.github-alert-rules-beta %}
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: Managing alerts that have been automatically dismissed by an alert rule
|
||||
intro: 'You can filter to see which alerts have been auto-dismissed by an alert rule, and you can reopen dismissed alerts.'
|
||||
allowTitleToDifferFromFilename: true
|
||||
versions:
|
||||
feature: dependabot-alert-rules-auto-dismissal-npm-dev-dependencies
|
||||
type: how_to
|
||||
topics:
|
||||
- Dependabot
|
||||
- Alerts
|
||||
- Vulnerabilities
|
||||
- Repositories
|
||||
- Dependencies
|
||||
shortTitle: Manage auto-dismissed alerts
|
||||
---
|
||||
|
||||
{% data reusables.dependabot.github-alert-rules-beta %}
|
||||
|
||||
## Managing automatically dismissed alerts
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** The {% data variables.product.prodname_dependabot_alerts %} page defaults to showing open alerts. To filter and view auto-dismissed alerts, you must first clear the `is:open` default filter from the view.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-security %}
|
||||
1. To filter to see all closed alerts, click **{% octicon "check" aria-hidden="true" %} Closed**. Alternatively, use the `is:closed` filter query in the search bar.
|
||||
|
||||

|
||||
|
||||
1. To see all auto-dismissed alerts, select **Closed as**, then in the dropdown menu, click **Auto-dismissed**.
|
||||
|
||||

|
||||
|
||||
1. To reopen an auto-dismissed alert, to the left of the alert title, click the checkbox adjacent to the alert, then click **Reopen**.
|
||||
|
||||

|
||||
@@ -0,0 +1,95 @@
|
||||
---
|
||||
title: Using GitHub-curated alert rules to prioritize Dependabot alerts
|
||||
intro: 'You can use a {% data variables.product.company_short %}-curated alert rule to auto-dismiss low impact development alerts for npm dependencies.'
|
||||
permissions: 'People with write permissions can view {% data variables.product.prodname_dependabot %} alert rules for the repository. People with with admin permissions to a repository, or the security manager role for the repository, can enable or disable {% data variables.product.prodname_dependabot %} alert rules for the repository.'
|
||||
versions:
|
||||
feature: dependabot-alert-rules-auto-dismissal-npm-dev-dependencies
|
||||
type: how_to
|
||||
topics:
|
||||
- Dependabot
|
||||
- Alerts
|
||||
- Vulnerabilities
|
||||
- Repositories
|
||||
- Dependencies
|
||||
shortTitle: GitHub-curated alert rules
|
||||
---
|
||||
|
||||
{% data reusables.dependabot.github-alert-rules-beta %}
|
||||
|
||||
## About {% data variables.product.company_short %}-curated alert rules
|
||||
|
||||
The {% data variables.product.company_short %}-curated alert rule, `Dismiss low impact alerts`, auto-dismisses certain types of vulnerabilities that are found in npm dependencies used in development. These alerts cover cases that feel like false alarms to most developers as the associated vulnerabilities:
|
||||
|
||||
- Are unlikely to be exploitable in a developer (non-production or runtime) environment.
|
||||
- May relate to resource management, programming and logic, and information disclosure issues.
|
||||
- At worst, have limited effects like slow builds or long-running tests.
|
||||
- Are not indicative of issues in production.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** Automatic dismissal of low impact development alerts is currently only supported for npm.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
The {% data variables.product.company_short %}-curated `Dismiss low impact alerts` rule includes vulnerabilities relating to resource management, programming and logic, and information disclosure issues. For more information, see "[Publicly disclosed CWEs used by the `Dismiss low impact alerts` rule](#publicly-disclosed-cwes-used-by-the-dismiss-low-impact-alerts-rule)."
|
||||
|
||||
Filtering out these low impact alerts allows you to focus on alerts that matter to you, without having to worry about missing potentially high-risk development-scoped alerts.
|
||||
|
||||
By default, {% data variables.product.company_short %}-curated {% data variables.product.prodname_dependabot %} alert rules are enabled on public repositories and disabled for private repositories. Administrators of private repositories can opt in by enabling alert rules for their repository.
|
||||
|
||||
## Enabling the `Dismiss low impact alerts` rule for your private repository
|
||||
|
||||
{% ifversion fpt or ghec %}You first need to enable {% data variables.product.prodname_dependabot_alerts %} for the repository. For more information, see "[AUTOTITLE](/code-security/dependabot/dependabot-alerts/configuring-dependabot-alerts#managing-dependabot-alerts-for-your-repository)."{% elsif ghes %}{% data variables.product.prodname_dependabot_alerts %} for your repository can be enabled or disabled by your enterprise owner. For more information, see "[AUTOTITLE](/admin/configuration/configuring-github-connect/enabling-dependabot-for-your-enterprise)."{% endif %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.repositories.navigate-to-code-security-and-analysis %}
|
||||
{% ifversion dependabot-alert-custom-rules-repo-level %}
|
||||
1. Under "{% data variables.product.prodname_dependabot_alerts %}", click {% octicon "gear" aria-label="The Gear icon" %} close to "{% data variables.product.prodname_dependabot %} rules".
|
||||
|
||||

|
||||
|
||||
1. Select **Dismiss low impact alerts**.
|
||||
1. Click **Save rules**.
|
||||
{% else %}
|
||||
1. Under "{% data variables.product.prodname_dependabot_alerts %}", click **Dismiss low impact alerts**.
|
||||
|
||||

|
||||
|
||||
{% endif %}
|
||||
|
||||
## Publicly disclosed CWEs used by the `Dismiss low impact alerts` rule
|
||||
|
||||
Along with the `ecosystem:npm` and `scope:development` alert metadata, we use the following {% data variables.product.company_short %}-curated Common Weakness Enumerations (CWEs) to filter out low impact alerts for the `Dismiss low impact alerts` rule. We regularly improve this list and vulnerability patterns covered by built-in rules.
|
||||
|
||||
### Resource Management Issues
|
||||
|
||||
- CWE-400 Uncontrolled Resource Consumption
|
||||
- CWE-770 Allocation of Resources Without Limits or Throttling
|
||||
- CWE-409 Improper Handling of Highly Compressed Data (Data Amplification)
|
||||
- CWE-908 Use of Uninitialized Resource
|
||||
- CWE-1333 Inefficient Regular Expression Complexity
|
||||
- CWE-835 Loop with Unreachable Exit Condition ('Infinite Loop')
|
||||
- CWE-674 Uncontrolled Recursion
|
||||
- CWE-1119 Excessive Use of Unconditional Branching
|
||||
|
||||
### Programming and Logic Errors
|
||||
|
||||
- CWE-185 Incorrect Regular Expression
|
||||
- CWE-754 Improper Check for Unusual or Exceptional Conditions
|
||||
- CWE-755 Improper Handling of Exceptional Conditions
|
||||
- CWE-248 Uncaught Exception
|
||||
- CWE-252 Unchecked Return Value
|
||||
- CWE-391 Unchecked Error Condition
|
||||
- CWE-696 Incorrect Behavior Order
|
||||
- CWE-1254 Incorrect Comparison Logic Granularity
|
||||
- CWE-665 Improper Initialization
|
||||
- CWE-703 Improper Check or Handling of Exceptional Conditions
|
||||
- CWE-178 Improper Handling of Case Sensitivity
|
||||
|
||||
### Information Disclosure Issues
|
||||
|
||||
- CWE-544 Missing Standardized Error Handling Mechanism
|
||||
- CWE-377 Insecure Temporary File
|
||||
- CWE-451 User Interface (UI) Misrepresentation of Critical Information
|
||||
- CWE-668 Exposure of Resource to Wrong Sphere
|
||||
@@ -18,7 +18,5 @@ children:
|
||||
- /about-dependabot-alerts
|
||||
- /configuring-dependabot-alerts
|
||||
- /viewing-and-updating-dependabot-alerts
|
||||
- /using-alert-rules-to-prioritize-dependabot-alerts
|
||||
- /configuring-notifications-for-dependabot-alerts
|
||||
---
|
||||
|
||||
|
||||
@@ -1,174 +0,0 @@
|
||||
---
|
||||
title: Using alert rules to prioritize Dependabot alerts
|
||||
intro: 'You can use {% data variables.product.prodname_dependabot %} alert rules to filter out false positive alerts or alerts you''re not interested in.'
|
||||
permissions: 'People with write permissions can view {% data variables.product.prodname_dependabot %} alert rules for the repository. People with with admin permissions to a repository, or the security manager role for the repository, can enable or disable {% data variables.product.prodname_dependabot %} alert rules for the repository{% ifversion dependabot-alert-custom-rules-repo-level %}, as well as create custom alert rules{% endif %}.'
|
||||
versions:
|
||||
feature: dependabot-alert-rules-auto-dismissal-npm-dev-dependencies
|
||||
type: how_to
|
||||
topics:
|
||||
- Dependabot
|
||||
- Alerts
|
||||
- Vulnerabilities
|
||||
- Repositories
|
||||
- Dependencies
|
||||
shortTitle: Alert rules
|
||||
---
|
||||
|
||||
{% data reusables.dependabot.github-alert-rules-beta %}
|
||||
|
||||
## About {% data variables.product.prodname_dependabot %} alert rules
|
||||
|
||||
{% data variables.product.prodname_dependabot %} alert rules allow you to instruct {% data variables.product.prodname_dependabot %} to automatically dismiss or reopen certain alerts, based on complex logic from a variety of contextual criteria.
|
||||
|
||||
{% ifversion dependabot-alert-custom-rules-repo-level %}
|
||||
There are two types of {% data variables.product.prodname_dependabot %} alert rules:
|
||||
|
||||
- {% data variables.product.company_short %}-curated rules
|
||||
- User-created custom rules
|
||||
|
||||
{% data variables.product.company_short %}-curated rules are enabled by default for public repositories and can be opted into for private repositories. However, it's important to note that you cannot modify the {% data variables.product.company_short %}-curated rules. With user-created custom rules, you can create your own rules to automatically dismiss or reopen alerts based on your own criteria.{% endif %}
|
||||
|
||||
Whilst you may find it useful to auto-dismiss low impact alerts, you can still reopen auto-dismissed alerts and filter to see which alerts have been auto-dismissed. For more information, see "[Managing automatically dismissed alerts](#managing-automatically-dismissed-alerts)."
|
||||
|
||||
Additionally, auto-dismissed alerts are still available for reporting and reviewing, and can be auto-reopened if the alert metadata changes, for example:
|
||||
- If you change the scope of a dependency from development to production.
|
||||
- If {% data variables.product.company_short %} modifies certain metadata for the related advisory.
|
||||
|
||||
Auto-dismissed alerts are defined by the `resolution:auto-dismiss` close reason. Automatic dismissal activity is included in alert webhooks, REST and GraphQL APIs, and the audit log. For more information, see "[AUTOTITLE](/rest/dependabot/alerts)" in the REST API documentation, and the "`repository_vulnerability_alert` " section in "[AUTOTITLE](/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/reviewing-the-audit-log-for-your-organization#repository_vulnerability_alert)."
|
||||
|
||||
## About {% data variables.product.company_short %}-curated rules
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** Automatic dismissal of low impact development alerts is currently only supported for npm.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
When enabled, the built-in `Dismiss low impact alerts` rule auto-dismisses certain types of vulnerabilities that are found in npm dependencies used in development. These alerts cover cases that feel like false alarms to most developers as the associated vulnerabilities:
|
||||
|
||||
- Are unlikely to be exploitable in a developer (non-production or runtime) environment.
|
||||
- May relate to resource management, programming and logic, and information disclosure issues.
|
||||
- At worst, have limited effects like slow builds or long-running tests.
|
||||
- Are not indicative of issues in production.
|
||||
|
||||
This {% data variables.product.company_short %}-curated `Dismiss low impact alerts` rule includes vulnerabilities relating to resource management, programming and logic, and information disclosure issues. For more information, see "[Publicly disclosed CWEs used by the `Dismiss low impact alerts` rule](#publicly-disclosed-cwes-used-by-the-dismiss-low-impact-alerts-rule)."
|
||||
|
||||
Filtering out these low impact alerts allows you to focus on alerts that matter to you, without having to worry about missing potentially high-risk development-scoped alerts.
|
||||
|
||||
By default, {% data variables.product.company_short %}-curated {% data variables.product.prodname_dependabot %} alert rules are enabled on public repositories and disabled for private repositories. Administrators of private repositories can opt in by enabling alert rules for their repository.
|
||||
|
||||
### Enabling the `Dismiss low impact alerts` rule for your private repository
|
||||
|
||||
{% ifversion fpt or ghec %}You first need to enable {% data variables.product.prodname_dependabot_alerts %} for the repository. For more information, see "[AUTOTITLE](/code-security/dependabot/dependabot-alerts/configuring-dependabot-alerts#managing-dependabot-alerts-for-your-repository)."{% elsif ghes %}{% data variables.product.prodname_dependabot_alerts %} for your repository can be enabled or disabled by your enterprise owner. For more information, see "[AUTOTITLE](/admin/configuration/configuring-github-connect/enabling-dependabot-for-your-enterprise)."{% endif %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.repositories.navigate-to-code-security-and-analysis %}
|
||||
{% ifversion dependabot-alert-custom-rules-repo-level %}
|
||||
1. Under "{% data variables.product.prodname_dependabot_alerts %}", click {% octicon "gear" aria-label="The Gear icon" %} close to "{% data variables.product.prodname_dependabot %} rules".
|
||||
|
||||

|
||||
|
||||
1. Select **Dismiss low impact alerts**.
|
||||
1. Click **Save rules**.
|
||||
{% else %}
|
||||
1. Under "{% data variables.product.prodname_dependabot_alerts %}", click **Dismiss low impact alerts**.
|
||||
|
||||

|
||||
|
||||
{% endif %}
|
||||
|
||||
{% ifversion dependabot-alert-custom-rules-repo-level %}
|
||||
## About user-created custom rules
|
||||
|
||||
You can create your own {% data variables.product.prodname_dependabot %} alert rules based on alert criteria.
|
||||
|
||||
- Dependency scope (`devDependency` or `runtime`)
|
||||
- Package name
|
||||
- CWE
|
||||
- Severity
|
||||
- Patch availability
|
||||
- Manifest path
|
||||
- Ecosystem
|
||||
|
||||
### Adding a custom rule to your repository
|
||||
|
||||
You can add a custom rule to your {% ifversion fpt %}public and private{% elsif ghec or ghes %}public, private, and internal{% endif %} repositories.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.repositories.navigate-to-code-security-and-analysis %}
|
||||
1. Under "{% data variables.product.prodname_dependabot_alerts %}", click {% octicon "gear" aria-label="The Gear icon" %} close to "{% data variables.product.prodname_dependabot %} rules".
|
||||
|
||||

|
||||
|
||||
1. Click **New ruleset**.
|
||||
|
||||

|
||||
|
||||
1. Under "Name", describe what this rule will do.
|
||||
1. Under "Alert criteria", select the criteria you want to use to filter alerts.
|
||||
1. Under "Rules", select the action you want to take on alerts that match the criteria.
|
||||
1. Click **Create rule**.
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Managing automatically dismissed alerts
|
||||
|
||||
You can filter to see which alerts have been auto-dismissed, and you can reopen dismissed alerts.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** The {% data variables.product.prodname_dependabot_alerts %} page defaults to showing open alerts. To filter and view auto-dismissed alerts, you must first clear the `is:open` default filter from the view.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-security %}
|
||||
1. To filter to see all closed alerts, click **{% octicon "check" aria-hidden="true" %} Closed**. Alternatively, use the `is:closed` filter query in the search bar.
|
||||
|
||||

|
||||
|
||||
1. To see all auto-dismissed alerts, select **Closed as**, then in the dropdown menu, click **Auto-dismissed**.
|
||||
|
||||

|
||||
|
||||
1. To reopen an auto-dismissed alert, to the left of the alert title, click the checkbox adjacent to the alert, then click **Reopen**.
|
||||
|
||||

|
||||
|
||||
## Publicly disclosed CWEs used by the `Dismiss low impact alerts` rule
|
||||
|
||||
Along with the `ecosystem:npm` and `scope:development` alert metadata, we use the following {% data variables.product.company_short %}-curated Common Weakness Enumerations (CWEs) to filter out low impact alerts for the `Dismiss low impact alerts` rule. We regularly improve this list and vulnerability patterns covered by built-in rules.
|
||||
|
||||
### Resource Management Issues
|
||||
|
||||
- CWE-400 Uncontrolled Resource Consumption
|
||||
- CWE-770 Allocation of Resources Without Limits or Throttling
|
||||
- CWE-409 Improper Handling of Highly Compressed Data (Data Amplification)
|
||||
- CWE-908 Use of Uninitialized Resource
|
||||
- CWE-1333 Inefficient Regular Expression Complexity
|
||||
- CWE-835 Loop with Unreachable Exit Condition ('Infinite Loop')
|
||||
- CWE-674 Uncontrolled Recursion
|
||||
- CWE-1119 Excessive Use of Unconditional Branching
|
||||
|
||||
### Programming and Logic Errors
|
||||
|
||||
- CWE-185 Incorrect Regular Expression
|
||||
- CWE-754 Improper Check for Unusual or Exceptional Conditions
|
||||
- CWE-755 Improper Handling of Exceptional Conditions
|
||||
- CWE-248 Uncaught Exception
|
||||
- CWE-252 Unchecked Return Value
|
||||
- CWE-391 Unchecked Error Condition
|
||||
- CWE-696 Incorrect Behavior Order
|
||||
- CWE-1254 Incorrect Comparison Logic Granularity
|
||||
- CWE-665 Improper Initialization
|
||||
- CWE-703 Improper Check or Handling of Exceptional Conditions
|
||||
- CWE-178 Improper Handling of Case Sensitivity
|
||||
|
||||
### Information Disclosure Issues
|
||||
|
||||
- CWE-544 Missing Standardized Error Handling Mechanism
|
||||
- CWE-377 Insecure Temporary File
|
||||
- CWE-451 User Interface (UI) Misrepresentation of Critical Information
|
||||
- CWE-668 Exposure of Resource to Wrong Sphere
|
||||
@@ -48,7 +48,7 @@ You can also audit actions taken in response to {% data variables.product.prodna
|
||||
|
||||
{% data variables.product.company_short %} helps you prioritize fixing {% data variables.product.prodname_dependabot_alerts %}. {% ifversion dependabot-most-important-sort-option %} By default, {% data variables.product.prodname_dependabot_alerts %} are sorted by importance. The "Most important" sort order helps you prioritize which {% data variables.product.prodname_dependabot_alerts %} to focus on first. Alerts are ranked based on their potential impact, actionability, and relevance. Our prioritization calculation is constantly being improved and includes factors like CVSS score, dependency scope, and whether vulnerable function calls are found for the alert.
|
||||
{% ifversion dependabot-alert-rules-auto-dismissal-npm-dev-dependencies %}
|
||||
You can also use alert rules to prioritize {% data variables.product.prodname_dependabot_alerts %}. For more information, see “[AUTOTITLE](/code-security/dependabot/dependabot-alerts/using-alert-rules-to-prioritize-dependabot-alerts).”
|
||||
You can also use alert rules to prioritize {% data variables.product.prodname_dependabot_alerts %}. For more information, see “[AUTOTITLE](/code-security/dependabot/dependabot-alert-rules/about-dependabot-alert-rules).”
|
||||
{% endif %}
|
||||
|
||||
{% data reusables.dependabot.dependabot-alerts-filters %}
|
||||
|
||||
@@ -327,6 +327,7 @@ If you use the same configuration as in the example above, bumping the `requests
|
||||
`pip dev: bump requests from 1.0.0 to 1.0.1`
|
||||
|
||||
{% ifversion dependabot-version-updates-groups %}
|
||||
|
||||
### `groups`
|
||||
|
||||
{% data reusables.dependabot.dependabot-version-updates-groups-supported %}
|
||||
|
||||
@@ -141,6 +141,7 @@ updates:
|
||||
```
|
||||
|
||||
{% ifversion dependabot-version-updates-groups %}
|
||||
|
||||
## Grouping {% data variables.product.prodname_dependabot_version_updates %} into one pull request
|
||||
|
||||
{% data reusables.dependabot.dependabot-version-updates-groups-about %}
|
||||
|
||||
@@ -16,8 +16,8 @@ topics:
|
||||
- Dependencies
|
||||
children:
|
||||
- /dependabot-alerts
|
||||
- /dependabot-alert-rules
|
||||
- /dependabot-security-updates
|
||||
- /dependabot-version-updates
|
||||
- /working-with-dependabot
|
||||
---
|
||||
|
||||
|
||||
@@ -277,6 +277,7 @@ npm can be configured to use the private registry's URL in lockfiles with `repla
|
||||
```shell
|
||||
npm config set replace-registry-host "never"
|
||||
```
|
||||
|
||||
{% endraw %}
|
||||
|
||||
If you use `replace-registry-host`, you must locally run `npm install` in order to regenerate the lockfile to use the private registry URL. {% data variables.product.prodname_dependabot %} will use the same URL when providing updates.
|
||||
@@ -377,6 +378,7 @@ registries:
|
||||
username: octocat@example.com
|
||||
password: ${{secrets.MY_AZURE_DEVOPS_TOKEN}}
|
||||
```
|
||||
|
||||
{% endraw %}
|
||||
{% raw %}
|
||||
|
||||
@@ -387,7 +389,9 @@ registries:
|
||||
url: https://pypi.fury.io/my_org
|
||||
token: ${{secrets.MY_GEMFURY_TOKEN}}
|
||||
```
|
||||
|
||||
{% endraw %}
|
||||
|
||||
#### Notes
|
||||
|
||||
{% data reusables.dependabot.access-private-dependencies-link %}
|
||||
@@ -407,6 +411,7 @@ registries:
|
||||
url: https://npm.pkg.github.com/<org-name>
|
||||
token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
|
||||
```
|
||||
|
||||
{% endraw %}
|
||||
|
||||
- For private registries, you have to check in a `.yarnrc.yml` file (for Yarn 3) or a `.yarnrc` file (for Yarn Classic).
|
||||
|
||||
@@ -70,7 +70,7 @@ If {% data variables.product.prodname_dependabot_alerts %} are enabled for a rep
|
||||
|
||||

|
||||
|
||||
You can filter {% data variables.product.prodname_dependabot_alerts %} in the list, using a variety of filters or labels. For more information, see "[AUTOTITLE](/code-security/dependabot/dependabot-alerts/viewing-and-updating-dependabot-alerts#prioritizing-dependabot-alerts)."{% ifversion dependabot-alert-rules-auto-dismissal-npm-dev-dependencies %} You can also use {% data variables.product.prodname_dependabot %} alert rules to filter out false positive alerts or alerts you're not interested in. For more information, see "[AUTOTITLE](/code-security/dependabot/dependabot-alerts/using-alert-rules-to-prioritize-dependabot-alerts)."{% endif %}
|
||||
You can filter {% data variables.product.prodname_dependabot_alerts %} in the list, using a variety of filters or labels. For more information, see "[AUTOTITLE](/code-security/dependabot/dependabot-alerts/viewing-and-updating-dependabot-alerts#prioritizing-dependabot-alerts)."{% ifversion dependabot-alert-rules-auto-dismissal-npm-dev-dependencies %} You can also use {% data variables.product.prodname_dependabot %} alert rules to filter out false positive alerts or alerts you're not interested in. For more information, see "[AUTOTITLE](/code-security/dependabot/dependabot-alert-rules/about-dependabot-alert-rules)."{% endif %}
|
||||
|
||||
1. Click the "Command Injection in lodash" alert on the _javascript/package-lock.json_ file. The details page for the alert will show the following information (note that some information may not apply to all alerts):
|
||||
- Whether {% data variables.product.prodname_dependabot %} created a pull request that will fix the vulnerability. You can review the suggested security update by clicking **Review security update**.
|
||||
@@ -95,6 +95,7 @@ If {% data variables.product.prodname_dependabot_alerts %} are enabled for a rep
|
||||

|
||||
|
||||
For more information about viewing, prioritizing, and sorting {% data variables.product.prodname_dependabot_alerts %}, see "[AUTOTITLE](/code-security/dependabot/dependabot-alerts/viewing-and-updating-dependabot-alerts)."
|
||||
|
||||
## Fixing or dismissing a {% data variables.product.prodname_dependabot %} alert
|
||||
|
||||
You can fix or dismiss {% data variables.product.prodname_dependabot_alerts %} on {% data variables.product.prodname_dotcom %}. Let's continue to use the forked repository as an example, and the "Command Injection in lodash" alert described in the previous section.
|
||||
|
||||
@@ -89,6 +89,7 @@ You can configure a _secret_scanning.yml_ file to exclude directories from {% da
|
||||
{% data reusables.files.add-file %}
|
||||
1. In the file name field, type _.github/secret_scanning.yml_.
|
||||
1. Under **Edit new file**, type `paths-ignore:` followed by the paths you want to exclude from {% data variables.product.prodname_secret_scanning %}.
|
||||
|
||||
``` yaml
|
||||
paths-ignore:
|
||||
- "foo/bar/*.js"
|
||||
|
||||
@@ -67,6 +67,7 @@ shortTitle: Manage secret alerts
|
||||
{% endif %}
|
||||
|
||||
{% ifversion secret-scanning-validity-check-partner-patterns %}
|
||||
|
||||
## Validating partner patterns
|
||||
|
||||
{% data reusables.secret-scanning.validity-check-partner-patterns-beta %}
|
||||
|
||||
@@ -34,7 +34,7 @@ See [`redirect_from`](https://github.com/github/docs/blob/main/content/README.md
|
||||
|
||||
If a URL for a page is entered without a version (`https://docs.github.com/ARTICLE` instead of `https://docs.github.com/VERSION/ARTICLE`), the site will automatically redirect it to the first available version of the page.
|
||||
|
||||
The order of precedence is specified in [`lib/all-versions.js`](https://github.com/github/docs/blob/main/lib/all-versions.js). The current order of precedence is:
|
||||
The order of precedence is specified in [`lib/all-versions.js`](https://github.com/github/docs/blob/main/src/versions/lib/all-versions.js). The current order of precedence is:
|
||||
|
||||
1. {% data variables.product.prodname_free_team %}, {% data variables.product.prodname_pro %}, or {% data variables.product.prodname_team %} (`fpt`)
|
||||
1. {% data variables.product.prodname_ghe_cloud %} (`ghec`)
|
||||
|
||||
@@ -18,16 +18,19 @@ For tasks that can be completed with different tools, the tool switcher signals
|
||||
When someone knows how they want to do a task and doesn’t need to see additional options, the tool switcher removes less relevant content, so they can find exactly what they need.
|
||||
|
||||
## Using tool tags
|
||||
|
||||
We use tool tags to divide information for each tool. On rare occasions, we will add new tools.
|
||||
|
||||
Tool tags are a key value pair. The key is the tag you use to refer to the tool in the article and the value is how the tool will be identified on the tool picker at the top of the article. The existing tools are in [`lib/all-tools.js`](https://github.com/github/docs/blob/main/src/tools/lib/all-tools.js) in the {% data variables.product.prodname_docs %} repository.
|
||||
|
||||
### When to use tool tags
|
||||
|
||||
We only use tool tags if an article must have tool-specific information to help people accomplish their tasks. If the conceptual information or procedural steps for a task are significantly different depending on what tool someone uses, and we want people to be able to accomplish the task with different tools, we use tool tags to present the relevant information in an article.
|
||||
|
||||
Do not use the tool switcher just to show examples in different languages. Only use the tool switcher if the tasks or concepts described in an article change based on what tool someone uses.
|
||||
|
||||
### How to use tool tags
|
||||
|
||||
Tool tags are Liquid tags that wrap content specific to a tool. <!--For more information on using tool tags in an article, see [AUTOTITLE](/contributing/using-markdown-and-liquid-in-github-docs#tool-tags)."-->
|
||||
|
||||
Put tools in alphabetical order. By default, the first tool tag will be selected for an article. You can define a different default tool for an article by specifying a `defaultTool:` property in the article's frontmatter. For more information, see the [content README](https://github.com/github/docs/blob/main/content/README.md#defaulttool).
|
||||
@@ -37,6 +40,7 @@ You can also link to an article with a specific tool selected by adding `?tool=T
|
||||
Only include a maximum of eight different tools in an article. Including more tools causes the tool switcher tabs to overflow with an article's table of contents, which prevents people from using either the tool switcher or table of contents. It is unlikely that you will ever need to include eight separate tools in an article. In general, plan to use as few separate tools as possible in an article.
|
||||
|
||||
## Adding new tools
|
||||
|
||||
If a writer determines that adding a new tool is the only way to accurately document something, they should explain their reasoning in the content planning stage. Whoever reviews content plan should consider if there are any alternative ways to address the documentation need without adding a new tool. If a new tool is the only way to create accurate documentation, the new tool should be added. If there is an alternative content solution that does not add a new tool, that option should be used.
|
||||
|
||||
To add a new tool, add an entry to the `allTools` object in the [`lib/all-tools.js`](https://github.com/github/docs/blob/main/src/tools/lib/all-tools.js) file as a key-value pair. Add new tools in alphabetical order.
|
||||
|
||||
@@ -102,6 +102,7 @@ const copyMe = true
|
||||
```
|
||||
|
||||
## Code sample annotations
|
||||
|
||||
Code sample annotations help explain longer code examples by rendering comments as annotations next to the sample code. This lets us write longer explanations of code without cluttering the code itself. Code samples with annotations are rendered in a two pane layout with the code sample on the left and the annotations on the right. The annotations are visually emphasized when someone hovers their cursor over the code example.
|
||||
|
||||
Code annotations only work in articles with the `layout: inline` frontmatter property. For more information on how to write and style code annotations, see "[AUTOTITLE](/contributing/syntax-and-versioning-for-github-docs/annotating-code-examples)."
|
||||
@@ -357,14 +358,19 @@ For example, if you include the following link in a content file:
|
||||
```
|
||||
/github/writing-on-github/creating-a-saved-reply
|
||||
```
|
||||
|
||||
When viewed on {% data variables.product.prodname_dotcom_the_website %} docs, the link gets rendered with the language code:
|
||||
|
||||
```
|
||||
/en/github/writing-on-github/creating-a-saved-reply
|
||||
```
|
||||
|
||||
and when viewed on {% data variables.product.prodname_ghe_server %} docs, the version is included as well:
|
||||
|
||||
```
|
||||
/en/enterprise-server@2.20/github/writing-on-github/creating-a-saved-reply
|
||||
```
|
||||
|
||||
For more information about links, see "[AUTOTITLE](/contributing/writing-for-github-docs/style-guide#links)."
|
||||
|
||||
### Permalinks
|
||||
|
||||
@@ -43,7 +43,7 @@ For more information, see [`lib/frontmatter.js`](https://github.com/github/docs/
|
||||
|
||||
### `versions`
|
||||
|
||||
- Purpose: Indicates the [versions](https://github.com/github/docs/blob/main/lib/all-versions.js) to which a page applies.
|
||||
- Purpose: Indicates the [versions](https://github.com/github/docs/blob/main/src/versions/lib/all-versions.js) to which a page applies.
|
||||
For more information about the different types of versioning, see "[Versioning documentation](/contributing/syntax-and-versioning-for-github-docs/versioning-documentation)."
|
||||
- Type: `Object`. Allowable keys map to product names and can be found in the `versions` object in [`lib/frontmatter.js`](https://github.com/github/docs/blob/main/lib/frontmatter.js).
|
||||
- This frontmatter value is currently **required** for all pages.
|
||||
@@ -221,6 +221,7 @@ defaultTool: cli
|
||||
```
|
||||
|
||||
### `learningTracks`
|
||||
|
||||
- Purpose: Render a list of learning tracks on a product's sub-landing page.
|
||||
- type: `String`. This should reference learning tracks' names defined in [`data/learning-tracks/*.yml`](https://github.com/github/docs/tree/main/data/learning-tracks).
|
||||
- Optional
|
||||
@@ -232,6 +233,7 @@ defaultTool: cli
|
||||
{% endnote %}
|
||||
|
||||
### `includeGuides`
|
||||
|
||||
- Purpose: Render a list of articles, filterable by `type` and `topics`. Only applicable when used with `layout: product-guides`.
|
||||
- Type: `Array`
|
||||
- Optional.
|
||||
@@ -247,21 +249,25 @@ includeGuides:
|
||||
```
|
||||
|
||||
### `type`
|
||||
|
||||
- Purpose: Indicate the type of article.
|
||||
- Type: `String`, one of the `overview`, `quick_start`, `tutorial`, `how_to`, `reference`.
|
||||
- Optional.
|
||||
|
||||
### `topics`
|
||||
|
||||
- Purpose: Indicate the topics covered by the article. The topics are used to filter guides on some landing pages. For example, the guides at the bottom of "[Guides for {% data variables.product.prodname_actions %}](/actions/guides#all-guides)" can be filtered by topics, and the topics are listed under the guide intro. Refer to the content models for more details about adding topics. A full list of existing topics is located in the [allowed topics file](https://github.com/github/docs/blob/main/data/allowed-topics.js). If topics in article frontmatter and the allow-topics list become out of sync, the [topics CI test](https://github.com/github/docs/blob/main/src/search/tests/topics.js) will fail.
|
||||
- Type: Array of `String`s
|
||||
- Optional: Topics are preferred for each article, but, there may be cases where existing articles don't yet have topics, or adding a topic to a new article may not add value.
|
||||
|
||||
### `communityRedirect`
|
||||
|
||||
- Purpose: Set a custom link and link name for `Ask the GitHub community` link in the footer.
|
||||
- Type: `Object`. Properties are `name` and `href`.
|
||||
- Optional.
|
||||
|
||||
### `effectiveDate`
|
||||
|
||||
- Purpose: Set an effective date for Terms of Service articles so that engineering teams can automatically re-prompt users to confirm the terms
|
||||
- Type: `string` YEAR-MONTH-DAY e.g. 2021-10-04 is October 4th, 2021
|
||||
- Optional.
|
||||
|
||||
@@ -65,7 +65,7 @@ For {% data variables.product.prodname_ghe_cloud %}, use `enterprise-cloud@lates
|
||||
|
||||
### {% data variables.product.prodname_ghe_server %}
|
||||
|
||||
Documentation for {% data variables.product.prodname_ghe_server %} has multiple versions and can be divided into two types: documentation for _supported releases_ (we support four at any one time), and documentation for _deprecated releases_ (we do not link to these on the Docs site but we support a "frozen" snapshot of these docs in perpetuity, so they can still be accessed if you know the URLs). See [`lib/enterprise-server-releases.js`](https://github.com/github/docs/blob/main/lib/enterprise-server-releases.js) for a list.
|
||||
Documentation for {% data variables.product.prodname_ghe_server %} has multiple versions and can be divided into two types: documentation for _supported releases_ (we support four at any one time), and documentation for _deprecated releases_ (we do not link to these on the Docs site but we support a "frozen" snapshot of these docs in perpetuity, so they can still be accessed if you know the URLs). See [`lib/enterprise-server-releases.js`](https://github.com/github/docs/blob/main/src/versions/lib/enterprise-server-releases.js) for a list.
|
||||
|
||||
The versions are named `enterprise-server@<release>`. The short name is `ghes`. In Liquid conditionals, we can specify ranges, like `ghes > 3.0`. For more information, see "[Versioning with Liquid conditional operators](#versioning-with-liquid-conditional-operators)."
|
||||
|
||||
@@ -259,7 +259,7 @@ You can version documentation to appear in the current {% data variables.product
|
||||
|
||||
### About the displayed version of {% data variables.product.prodname_ghe_managed %} documentation
|
||||
|
||||
We display one version of {% data variables.product.prodname_ghe_managed %} documentation on {% data variables.product.prodname_docs %}: the latest. We define "latest" in the site's source, within [`all-versions.js`](https://github.com/github/docs/blob/main/lib/all-versions.js#L58). In almost all cases, this value is a safe place to determine the latest public release of {% data variables.product.prodname_ghe_managed %}.
|
||||
We display one version of {% data variables.product.prodname_ghe_managed %} documentation on {% data variables.product.prodname_docs %}: the latest. We define "latest" in the site's source, within [`all-versions.js`](https://github.com/github/docs/blob/main/src/versions/lib/all-versions.js#L58). In almost all cases, this value is a safe place to determine the latest public release of {% data variables.product.prodname_ghe_managed %}.
|
||||
|
||||
"Latest" corresponds with the latest version of {% data variables.product.prodname_ghe_managed %} that we've deployed to the first customer using the product in production. Generally, {% data variables.product.company_short %} upgrades all production customers on {% data variables.product.prodname_ghe_managed %} to the latest version around the same time, so Product considers only showing the latest documentation an acceptable compromise.
|
||||
|
||||
|
||||
@@ -48,6 +48,7 @@ Top-level doc sets are organized around a {% data variables.product.prodname_dot
|
||||
- Most top-level doc sets have a landing page layout, unless there is a significant exception. For example, the "[Site policy](/free-pro-team@latest/site-policy)" doc set does not have guides or procedural articles like other doc sets, so it does not use a landing page layout.
|
||||
|
||||
#### Titles for top-level doc sets
|
||||
|
||||
- Feature or product based.
|
||||
- Describes what part of {% data variables.product.prodname_dotcom %} someone is using.
|
||||
- Examples
|
||||
@@ -63,6 +64,7 @@ Categories are organized around a feature or a discrete set of tasks within a to
|
||||
- When categories have more than ten articles, consider breaking the content into map topics or additional categories.
|
||||
|
||||
#### Titles for categories
|
||||
|
||||
- Task-based (begins with a gerund).
|
||||
- Describes the big-picture purpose or goal of using the feature or product.
|
||||
- General or high-level enough to scale with future product enhancements.
|
||||
@@ -72,6 +74,7 @@ Categories are organized around a feature or a discrete set of tasks within a to
|
||||
- [AUTOTITLE](/pull-requests/committing-changes-to-your-project)
|
||||
|
||||
#### Intros for categories
|
||||
|
||||
All categories have intros. Intros should be one sentence long and general or high-level enough to scale with future product changes. If you significantly change a category’s structure, check its intro for needed updates.
|
||||
|
||||
### Map topic
|
||||
@@ -81,6 +84,7 @@ Map topics introduce a section of a category, grouping articles within a categor
|
||||
Map topics contain at least three articles. When map topics have more than eight articles, it may be useful to consider breaking the content into more specific map topics.
|
||||
|
||||
#### Titles for map topics
|
||||
|
||||
- Task-based (begins with a gerund).
|
||||
- Describes a more specific task within the larger workflow of the category it’s in.
|
||||
- General or high-level enough to scale with future additions to the product.
|
||||
@@ -90,6 +94,7 @@ Map topics contain at least three articles. When map topics have more than eight
|
||||
- [AUTOTITLE](/enterprise-cloud@latest/admin/user-management/managing-users-in-your-enterprise)
|
||||
|
||||
#### Intros for map topics
|
||||
|
||||
All map topics have intros. Intros should be one sentence long and general or high-level enough to scale with future product changes. If you add or remove articles in a map topic, check its intro for needed updates.
|
||||
|
||||
### Article
|
||||
@@ -113,6 +118,7 @@ We organize content predictably within categories, map topics, and articles. Fro
|
||||
Topics are used to filter articles and are searchable across the {% data variables.product.prodname_docs %} site. For some layouts, such as landing pages or guides, people can select which articles are displayed by filtering topics. Use these guidelines to help choose which topics to add to an article's frontmatter. For more information on adding topics to an article see, "[Topics](https://github.com/github/docs/tree/main/content#topics)" and for a list of all allowed topics, see [`allowed-topics`](https://github.com/github/docs/blob/main/data/allowed-topics.js).
|
||||
|
||||
#### Topics for all content types
|
||||
|
||||
- All articles should have at least one topic
|
||||
- Use nouns as topics
|
||||
- Topics help people meaningfully group content
|
||||
@@ -131,6 +137,7 @@ Topics are used to filter articles and are searchable across the {% data variabl
|
||||
- Use: `Actions` instead of `GitHub Actions`
|
||||
|
||||
#### Checklist for choosing topics
|
||||
|
||||
Consider these questions to help choose topics for an article. Not every article will have a topic for each item in the checklist.
|
||||
|
||||
- What is the feature or product area?
|
||||
@@ -172,12 +179,14 @@ For the conceptual content template, see "[AUTOTITLE](/contributing/writing-for-
|
||||
- Include next steps for getting started with the feature (whether through further reading links or content within the article itself).
|
||||
|
||||
#### Titles for conceptual content
|
||||
|
||||
- Conceptual articles or headers of conceptual sections start with "About [subject]”.
|
||||
- Use a noun to describe the subject.
|
||||
- Use: "About {% data variables.product.prodname_code_scanning %}"
|
||||
- Avoid: "About scanning your code for vulnerabilities"
|
||||
|
||||
#### Examples of conceptual content
|
||||
|
||||
- Conceptual articles
|
||||
- [About GitHub Sponsors](/free-pro-team@latest/sponsors/getting-started-with-github-sponsors/about-github-sponsors)
|
||||
- [About Enterprise accounts](/enterprise-cloud@latest/admin/overview/about-enterprise-accounts)
|
||||
@@ -209,11 +218,13 @@ For the referential content template, see "[AUTOTITLE](/contributing/writing-for
|
||||
- Example: [AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions)
|
||||
|
||||
#### Titles for referential content
|
||||
|
||||
- Referential articles or headers of referential sections clearly describe the contents of the section, and generally begin with nouns.
|
||||
- Titles include enough information to be accessible to novice users and fully describe the contents of each section.
|
||||
- Titles avoid stacked nouns - use prepositions to break up long strings of nouns.
|
||||
|
||||
#### Examples of referential content
|
||||
|
||||
- Referential articles
|
||||
- [AUTOTITLE](/get-started/using-github/keyboard-shortcuts)
|
||||
- [AUTOTITLE](/enterprise-cloud@latest/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)
|
||||
@@ -242,6 +253,7 @@ For the procedural content template, see "[AUTOTITLE](/contributing/writing-for-
|
||||
- Include troubleshooting tips as frequently as possible.
|
||||
|
||||
#### Titles for procedural content
|
||||
|
||||
- Procedural articles or procedural sections within articles are task-based and begin with a gerund.
|
||||
- Use: "Applying for a student developer pack"
|
||||
- Use active and specific verbs (brainstorm or use a thesaurus when needed).
|
||||
@@ -249,9 +261,10 @@ For the procedural content template, see "[AUTOTITLE](/contributing/writing-for-
|
||||
- Article title length: maximum 80 characters, 60 if possible.
|
||||
|
||||
#### Examples of procedural content
|
||||
|
||||
- [AUTOTITLE](/free-pro-team@latest/billing/managing-your-github-billing-settings/adding-information-to-your-receipts)
|
||||
- [AUTOTITLE](/enterprise-cloud@latest/admin/user-management/managing-users-in-your-enterprise/inviting-people-to-manage-your-enterprise)
|
||||
- [AUTOTITLE](/actions/using-workflows/using-starter-workflows)
|
||||
- [AUTOTITLE](/actions/learn-github-actions/using-starter-workflows)
|
||||
|
||||
### Release notes
|
||||
|
||||
@@ -274,6 +287,7 @@ You can find guidance for the format, style, and tone of release notes, as well
|
||||
Troubleshooting content includes built-in errors we expect people to encounter, common problems reported to support, and situations people might encounter while completing tasks. Use troubleshooting sections in guides or procedural articles to keep solutions close to procedures. Work with support and product managers to surface common errors and include them in the documentation.
|
||||
|
||||
#### Known issues
|
||||
|
||||
Known issues are a subset of troubleshooting content specifically designed to respond to bugs, UX/UI issues, and other product quirks that generate a high volume of support tickets. Where troubleshooting content can describe errors that people *might* encounter, known issues explain problems that people *will* encounter.
|
||||
|
||||
Like all troubleshooting content, known issues can be a section in an article or a standalone article. If a known issue applies to a specific article, document it in that article. If a known issue applies to a specific set of articles or conceptual grouping of features, or if a product or feature has multiple known issues that should be grouped together, create a dedicated "Known issues with NAME" article.
|
||||
@@ -289,17 +303,20 @@ Use known issues to explain the following situations.
|
||||
- Rare or severe bugs that {% data variables.product.prodname_dotcom %} has not yet prioritized fixing, and that are not explained in the product or by existing content on {% data variables.product.prodname_docs %}.
|
||||
|
||||
#### How to write troubleshooting content
|
||||
|
||||
- Use any {% data variables.product.prodname_docs %} content type to create troubleshooting sections.
|
||||
- Whenever possible, keep troubleshooting content contained within procedural content or guides.
|
||||
- You can create a troubleshooting article when it makes sense to keep it separate, such as when there’s a large amount of troubleshooting content on a particular topic.
|
||||
- You can create a troubleshooting map topic if a product or feature has many troubleshooting articles, for example "[AUTOTITLE](/authentication/troubleshooting-ssh)."
|
||||
|
||||
#### Title guidelines for troubleshooting content
|
||||
|
||||
- Troubleshooting FEATURE
|
||||
- Error: ERROR NAME
|
||||
- Known issues for PRODUCT
|
||||
|
||||
#### Examples of troubleshooting content
|
||||
|
||||
- "[AUTOTITLE](/authentication/troubleshooting-ssh)"
|
||||
- "[AUTOTITLE](/enterprise-server@latest/admin/configuration/configuring-network-settings/using-github-enterprise-server-with-a-load-balancer#troubleshooting-connectivity-through-a-load-balancer)"
|
||||
- "[Known issues](/enterprise-server@3.7/admin/release-notes#3.7.8-known-issues)" in the {% data variables.product.prodname_ghe_server %} release notes
|
||||
@@ -310,6 +327,7 @@ Use known issues to explain the following situations.
|
||||
Often, it's helpful to group information in context to help people complete a complex task, understand a set of related tasks, or illustrate an entire workflow. Use longer articles combining content types to ensure people find contextual content in the right place. Longer articles also help eliminate duplication of content and prepare content to scale as more options are added to the product. People most often need longer articles while actively using the product, and they may need to consult the article at different points on their journey.
|
||||
|
||||
#### How to combine multiple content types in an article
|
||||
|
||||
- Use conceptual, procedural, referential, troubleshooting, or known issue content in a longer article, and do not use quickstart or tutorials.
|
||||
- Use sections of different content types in the article as needed, and follow title guidelines for the content type.
|
||||
- Most often, these articles will contain at least one procedural section plus at least one additional conceptual, referential, or procedural section.
|
||||
@@ -318,11 +336,13 @@ Often, it's helpful to group information in context to help people complete a co
|
||||
- You can replicate the article’s title in a header if needed.
|
||||
|
||||
#### Title guidelines for articles that combine multiple content types
|
||||
|
||||
- If there is a procedure within the article, use a task-based title that begins with a gerund.
|
||||
- Titles are general enough to describe the range of information and tasks contained within the article.
|
||||
- Titles describe the setting being toggled and are agnostic about what setting the reader chooses, e.g., "Setting repository visibility” instead of "Making a private repository public.”
|
||||
|
||||
#### Examples of articles that combine multiple content types
|
||||
|
||||
- [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility)
|
||||
- [AUTOTITLE](/enterprise-cloud@latest/admin/policies/enforcing-policies-for-your-enterprise/enforcing-repository-management-policies-in-your-enterprise)
|
||||
- [AUTOTITLE](/free-pro-team@latest/billing/managing-billing-for-your-github-account/upgrading-your-github-subscription)
|
||||
@@ -358,10 +378,12 @@ Contents of quickstarts:
|
||||
- Include 2-3 actionable next steps that someone can take after completing the quickstart. Always link to conceptual content on the feature or product. You can also link off to other related information on docs.github.com or in {% data variables.product.prodname_learning %}.
|
||||
|
||||
#### Title guidelines for quickstarts
|
||||
|
||||
- When the guide helps someone get started with a new tool, preface the title with "Quickstart", e.g. "Quickstart for GitHub Actions" or "Quickstart: Procedural title."
|
||||
- For other use cases, follow the title guidelines for procedures and omit the word "Quickstart."
|
||||
|
||||
#### Examples of quickstarts
|
||||
|
||||
- [AUTOTITLE](/free-pro-team@latest/actions/quickstart)
|
||||
- [AUTOTITLE](/free-pro-team@latest/discussions/quickstart)
|
||||
- [Quickstart for GitHub Educators](/free-pro-team@latest/education/quickstart)
|
||||
@@ -403,10 +425,12 @@ Contents of tutorials:
|
||||
- Relevant published talks, blog posts, or Community Forum series posts by Hubbers
|
||||
|
||||
#### Title guidelines for tutorials
|
||||
|
||||
- Follow the title guidelines for procedural articles.
|
||||
- Do not use "tutorial” or "guide” in the title.
|
||||
|
||||
#### Examples of tutorials
|
||||
|
||||
Tutorials:
|
||||
- [AUTOTITLE](/actions/managing-issues-and-pull-requests/adding-labels-to-issues)
|
||||
- [AUTOTITLE](/actions/deployment/deploying-xcode-applications/installing-an-apple-certificate-on-macos-runners-for-xcode-development)
|
||||
@@ -448,6 +472,7 @@ Titles fully describe what a page is about, and what someone will learn by readi
|
||||
Titles can be challenging. Use these general guidelines to help create clear, helpful, and descriptive titles. The guidelines for each content type in this article provide more specific title rules.
|
||||
|
||||
#### Titles for all content types
|
||||
|
||||
- Titles clearly describe what a page is about. They are descriptive and specific.
|
||||
- Use: Browsing actions in the workflow editor
|
||||
- Use: Example of configuring a codespace
|
||||
@@ -480,6 +505,7 @@ Use the product callout when a feature is available in specific products only an
|
||||
All product callouts are stored as reusables in [`gated-features`](https://github.com/github/docs/tree/main/data/reusables/gated-features) and added in YAML frontmatter for relevant articles.
|
||||
|
||||
#### How to write a product callout
|
||||
|
||||
- Product callouts follow a strict format, clearly identifying the feature and which products it’s available in.
|
||||
- Product callouts also include a link to "GitHub’s products” and occasionally to another relevant article.
|
||||
- Examples:
|
||||
@@ -487,6 +513,7 @@ All product callouts are stored as reusables in [`gated-features`](https://githu
|
||||
- [Feature name] is available in public repositories with [free product(s)], and in public and private repositories with [paid products]. For more information, see "GitHub’s products.”
|
||||
|
||||
#### Examples of articles with product callouts
|
||||
|
||||
Check the source files and `gated-features` to see how source content is written.
|
||||
- [AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule)
|
||||
|
||||
@@ -495,6 +522,7 @@ Check the source files and `gated-features` to see how source content is written
|
||||
The top of every page has an intro that provides context and sets expectations, allowing readers to quickly decide if the page is relevant to them. Intros also are displayed in search results to provide contextual information to help readers choose a result.
|
||||
|
||||
#### How to write an intro
|
||||
|
||||
- Article intros are one to two sentences long.
|
||||
- Map topic and category intros are one sentence long.
|
||||
- API reference intros are one sentence long.
|
||||
@@ -513,6 +541,7 @@ Every procedure includes a permissions statement explaining the role required to
|
||||
Occasionally, it's relevant to mention required permissions in conceptual content, especially in standalone conceptual articles. Make sure to also include a permissions statement in related procedures (or write a longer article combining all of the content).
|
||||
|
||||
#### How to write a permissions statement
|
||||
|
||||
- When a single set of permissions applies to all procedures in an article, use the [permissions frontmatter](https://github.com/github/docs/tree/main/content#permissions).
|
||||
- When an article contains multiple procedures and different permissions apply, include a separate permissions statement under each relevant header, before each procedure.
|
||||
- Don't include permissions in an article’s intro.
|
||||
@@ -523,6 +552,7 @@ Occasionally, it's relevant to mention required permissions in conceptual conten
|
||||
- AVOID: [ACCOUNT ROLE] and people with [FEATURE ROLE] access for a [FEATURE] can [ACTION].
|
||||
|
||||
#### Examples of permissions statements
|
||||
|
||||
- Article with single permissions statement for multiple procedures: [AUTOTITLE](/enterprise-cloud@latest/admin/policies/enforcing-policies-for-your-enterprise/enforcing-repository-management-policies-in-your-enterprise)
|
||||
|
||||
### Tool switcher
|
||||
@@ -530,12 +560,15 @@ Occasionally, it's relevant to mention required permissions in conceptual conten
|
||||
Some articles have content that varies depending on what tool someone uses to complete a task, such as the {% data variables.product.prodname_cli %} or {% data variables.product.prodname_desktop %}. For most content, the same conceptual or procedural information will be accurate for multiple tools. However, if the only way to make information clear and accurate is by distinguishing content by tool, use the tool switcher. Do not use the tool switcher just to show examples in different languages. Only use the tool switcher if the tasks or concepts change based on what tool someone uses. For more information on using the tool switcher, see the [tool switcher content model](https://github.com/github/docs/blob/main/contributing/tool-switcher.md).
|
||||
|
||||
### Table of contents
|
||||
|
||||
Tables of contents are automatically generated. For more information see "[Autogenerated mini-TOCs](https://github.com/github/docs/tree/main/content#autogenerated-mini-tocs)."
|
||||
|
||||
### Conceptual content
|
||||
|
||||
Conceptual content helps people understand or learn about a topic. See "[Conceptual](#conceptual)" above.
|
||||
|
||||
### Referential content
|
||||
|
||||
Referential content provides structured information related to actively using a product or feature. See "[Referential](#referential)" above.
|
||||
|
||||
### Prerequisites
|
||||
@@ -543,6 +576,7 @@ Referential content provides structured information related to actively using a
|
||||
Prerequisites are information that people need to know before proceeding with a procedure, so that they can prepare everything they need before starting the task.
|
||||
|
||||
#### How to write prerequisites
|
||||
|
||||
- Write prerequisites immediately before a procedure's numbered steps.
|
||||
- You can use a list, a sentence, or a paragraph to explain prerequisites.
|
||||
- You can also use a separate prerequisites section when:
|
||||
@@ -551,13 +585,16 @@ Prerequisites are information that people need to know before proceeding with a
|
||||
- To repeat or highlight important information about data loss or destructive actions, you may also use a warning or danger callout to share a prerequisite.
|
||||
|
||||
#### Title guidelines for prerequisites
|
||||
|
||||
- When using a separate section, use a header called `Prerequisites`
|
||||
|
||||
#### Examples of articles with prerequisites sections
|
||||
|
||||
- [AUTOTITLE](/enterprise-server@latest/admin/installation/installing-github-enterprise-server-on-aws)
|
||||
- [AUTOTITLE](/enterprise-server@latest/admin/configuration/enabling-subdomain-isolation)
|
||||
|
||||
### Procedural content
|
||||
|
||||
Procedural content helps people complete tasks. See "[Procedural](#procedural)" above.
|
||||
|
||||
### Troubleshooting content
|
||||
@@ -569,10 +606,12 @@ Troubleshooting content helps people avoid or work through errors. See "[Trouble
|
||||
Further reading sections highlight additional targeted articles that aren’t already included within the article’s content or sidebar. Use further reading sections sparingly when they provide real value.
|
||||
|
||||
#### How to write a further reading section
|
||||
|
||||
- Use a bulleted list.
|
||||
- Use further reading sections sparingly and when they provide high value - see style guide for guidelines on linking.
|
||||
|
||||
#### Title and format for further reading sections
|
||||
|
||||
```
|
||||
### Further reading
|
||||
- "[Article title](article-URL)”
|
||||
|
||||
@@ -471,6 +471,7 @@ For more information, see "[AUTOTITLE](PATH-TO-ARTICLE#HEADER-TITLE)."
|
||||
```
|
||||
|
||||
To link to two or more specific headers in a different article, use this format:
|
||||
|
||||
```
|
||||
For more information, see "[HEADER-TITLE-1](PATH-TO-ARTICLE#SECTION-LINK-1)" and "[HEADER-TITLE-2](PATH-TO-ARTICLE#SECTION-LINK-2)" in "ARTICLE-TITLE."
|
||||
```
|
||||
@@ -1006,6 +1007,7 @@ For example in the following table, in order to make sense of the "Yes" and "No"
|
||||
To add row headers for a Markdown table, wrap the table in the Liquid tags `{% raw %}{% rowheaders %} {% endrowheaders %}{% endraw %}`. For more information about using row headers, see "[AUTOTITLE](/contributing/syntax-and-versioning-for-github-docs/using-markdown-and-liquid-in-github-docs#table-row-headers)."
|
||||
|
||||
### Include a value for every cell
|
||||
|
||||
Every cell in a table must contain a value. If the table has row headers, the first cell (cell A1) can be empty.
|
||||
|
||||
If there is no data, use "None" or "Not applicable". Do not use "NA" or "N/A".
|
||||
@@ -1022,6 +1024,7 @@ For tables that use symbols:
|
||||
Where table data is not truly binary (every value is either "Yes" or "No", for example), text values may be needed in addition to, or instead of, symbols. For example on the page "[AUTOTITLE](/support/learning-about-github-support/about-github-support)", some features are marked as "Available to purchase".
|
||||
|
||||
### Use footnotes sparingly
|
||||
|
||||
See "[Footnotes](#footnotes)."
|
||||
|
||||
### Align table content consistently
|
||||
@@ -1106,6 +1109,7 @@ Use quotation marks around article titles, whether the article is hosted on GitH
|
||||
For further guidance, see “[Formatting titles](https://docs.microsoft.com/style-guide/text-formatting/formatting-titles)” in Microsoft’s Style Guide.
|
||||
|
||||
## Short titles
|
||||
|
||||
We use short titles to populate the sidebar navigation. Since short titles appear in the sidebar navigation, they can use context to convey meaning and be slightly less precise than full titles. The goal of short titles is to help people find the content that they are looking for without having sidebar navigation items that are too long. Short titles give people contextual understanding of an article and align to the following standards.
|
||||
|
||||
- Short titles are 2-3 words long.
|
||||
@@ -1195,6 +1199,7 @@ When referencing text in the user interface, reproduce the text exactly. Use quo
|
||||
- **Use:** Under “IP allow list”, click **Edit**.
|
||||
|
||||
### More resources
|
||||
|
||||
Microsoft Style Guide:
|
||||
- [Formatting text in instructions](https://docs.microsoft.com/style-guide/procedures-instructions/formatting-text-in-instructions)
|
||||
|
||||
|
||||
@@ -45,18 +45,21 @@ Good videos introduce an instructional agenda that includes steps and goals so t
|
||||
Videos are broadly grouped into three categories: product overviews, feature videos, and tutorials. These descriptions are generalizations of each video type. Some videos might not fit perfectly in one category, but can still be useful without meeting the exact guidelines.
|
||||
|
||||
### Product overviews
|
||||
|
||||
- **Purpose**: Briefly explain what the product is, showcase the main functionality, and get people interested
|
||||
- **Length**: Less than a minute
|
||||
- **Possible audiences**: People who want to know if a feature is useful for their goals, people who are new to {% data variables.product.company_short %} and trying to understand what the products do
|
||||
- **Possible locations in the docs**: Landing pages and guides
|
||||
|
||||
### Feature videos
|
||||
|
||||
- **Purpose**: Supplement conceptual or procedural content
|
||||
- **Length**: As short as possible, without exceeding five minutes. Break longer content into multiple shorter, focused videos
|
||||
- **Possible audiences**: People who are learning about or how to use a feature
|
||||
- **Possible locations in the docs**: Guides, conceptual articles, procedural articles
|
||||
|
||||
### Tutorials
|
||||
|
||||
- **Purpose**: Help novice users get going with a product, drive adoption, or explain complex functionalities
|
||||
- **Length**: Individual videos should be five minutes or less. Complex topics can have a series of shorter videos spread across an article. Total length should be a maximum of 15 minutes
|
||||
- **Possible audiences**: New users of features or products
|
||||
|
||||
@@ -119,6 +119,7 @@ Alternatively, you can create the file manually and save it in the location for
|
||||
```xml copy
|
||||
<entry key="*" value="false" />
|
||||
```
|
||||
|
||||
1. Save the changes to the `github-copilot.xml` file.
|
||||
1. Restart your JetBrains IDE for the changes to take effect.
|
||||
|
||||
@@ -151,6 +152,7 @@ To deactivate {% data variables.product.prodname_copilot %} for all languages, t
|
||||
</component>
|
||||
</application>
|
||||
```
|
||||
|
||||
To specify languages individually, add an entry for each language you want to activate or deactivate {% data variables.product.prodname_copilot %} for. Specific language settings will override the wildcard. For example, to activate {% data variables.product.prodname_copilot %} for Python and YAML, and deactivate {% data variables.product.prodname_copilot %} for all other languages, add the following entries:
|
||||
|
||||
```xml copy
|
||||
|
||||
@@ -341,6 +341,8 @@ You can also use {% data variables.product.prodname_copilot %} to generate sugge
|
||||
|
||||
```javascript copy
|
||||
// Express server on port 3000
|
||||
```
|
||||
|
||||
1. To accept each line, press <kbd>Tab</kbd>, then <kbd>Enter</kbd>.
|
||||
1. Type the following comment and then press <kbd>Enter</kbd>. {% data variables.product.prodname_copilot %} will suggest an implementation for the default handler.
|
||||
|
||||
|
||||
@@ -16,7 +16,9 @@ shortTitle: Audit logs
|
||||
Audit logs for {% data variables.product.prodname_copilot_business_short %} can help you understand what actions have been taken and by whom. You can use the audit logs to review actions taken by users in your organization{% ifversion ghec %} or enterprise{% endif %}, such as changes to an organization's {% data variables.product.prodname_copilot_short %} settings and policies, or the addition or removal of seats from your {% data variables.product.prodname_copilot_business_short %} subscription. The audit log lists events related to your {% data variables.product.prodname_copilot_business_short %} subscription for the current month and previous six months. For more information, see{% ifversion ghec %} "[AUTOTITLE](/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/about-the-audit-log-for-your-enterprise)" or{% endif %} "[AUTOTITLE](/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/reviewing-the-audit-log-for-your-organization)."
|
||||
|
||||
## Viewing your organization{%- ifversion ghec %} or enterprise{% endif %}'s audit logs
|
||||
|
||||
{%- ifversion ghec %}
|
||||
|
||||
### Viewing your enterprise's audit logs
|
||||
|
||||
{% data reusables.enterprise-accounts.access-enterprise %}
|
||||
|
||||
@@ -60,6 +60,7 @@ If you find the log file doesn't contain enough information to resolve an issue,
|
||||
```text copy
|
||||
#com.github.copilot:trace
|
||||
```
|
||||
|
||||
1. Keep using your IDE until you encounter the issue again, then collect the log file as described in "[Collecting log files](#collecting-log-files)."
|
||||
1. When you have the information you need, disable debug mode by removing `#com.github.copilot:trace` from the "Custom Debug Log Configuration" window.
|
||||
|
||||
@@ -131,6 +132,7 @@ If you find the log file doesn't contain enough information to resolve an issue,
|
||||
}
|
||||
},
|
||||
```
|
||||
|
||||
1. Keep using your IDE until you encounter the issue again, then collect the log file as described in "[Viewing and collecting log files](#viewing-and-collecting-log-files)."
|
||||
1. When you have the information you need, disable debug mode by removing the content you added to your settings.
|
||||
|
||||
|
||||
@@ -17,7 +17,7 @@ shortTitle: Configure basic settings
|
||||
|
||||

|
||||
|
||||
{% indented_data_reference reusables.desktop.preferences-options-tabs spaces=3 %}
|
||||
{% data reusables.desktop.preferences-options-tabs %}
|
||||
|
||||
{% endmac %}
|
||||
|
||||
@@ -28,7 +28,7 @@ shortTitle: Configure basic settings
|
||||
|
||||

|
||||
|
||||
{% indented_data_reference reusables.desktop.preferences-options-tabs spaces=3 %}
|
||||
{% data reusables.desktop.preferences-options-tabs %}
|
||||
|
||||
{% endwindows %}
|
||||
|
||||
|
||||
@@ -57,7 +57,7 @@ Before you authenticate, {% data reusables.desktop.get-an-account %}
|
||||
|
||||
{% data reusables.desktop.sign-in-browser %}
|
||||
|
||||
{% indented_data_reference reusables.user-settings.password-authentication-deprecation-desktop spaces=3 %}
|
||||
{% data reusables.user-settings.password-authentication-deprecation-desktop %}
|
||||
|
||||
{% data reusables.desktop.authenticate-in-browser %}
|
||||
{% data reusables.desktop.2fa-in-browser %}
|
||||
|
||||
@@ -106,7 +106,7 @@ If you have an enterprise account, license use for the entire enterprise is show
|
||||
{% data reusables.advanced-security.starter-workflows-beta %}
|
||||
{% data reusables.advanced-security.starter-workflow-overview %}
|
||||
|
||||
For more information on starter workflows, see "[AUTOTITLE](/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/configuring-advanced-setup-for-code-scanning#configuring-code-scanning-using-third-party-actions)" and "[AUTOTITLE](/actions/using-workflows/using-starter-workflows)."
|
||||
For more information on starter workflows, see "[AUTOTITLE](/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/configuring-advanced-setup-for-code-scanning#configuring-code-scanning-using-third-party-actions)" and "[AUTOTITLE](/actions/learn-github-actions/using-starter-workflows)."
|
||||
|
||||
{% endif %}
|
||||
|
||||
|
||||
@@ -52,7 +52,7 @@ The following features are not included in the trial of {% data variables.produc
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** If you transfer an existing organization into your trial enterprise, all of these features will be disabled, but will be re-enabled if the organization is removed from the enterprise.
|
||||
**Note:** If you invite an existing organization into your trial enterprise, all of these features will be disabled, but will be re-enabled if the organization is removed from the enterprise.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
|
||||
@@ -252,6 +252,7 @@ You can create multiple levels of nested lists using the same method. For exampl
|
||||
For more examples, see the [GitHub Flavored Markdown Spec](https://github.github.com/gfm/#example-265).
|
||||
|
||||
{% ifversion task-lists-v1 %}
|
||||
|
||||
## Task lists
|
||||
|
||||
{% data reusables.repositories.task-list-markdown %}
|
||||
|
||||
@@ -74,6 +74,7 @@ Any issues that are referenced in a task list specify that they are tracked by t
|
||||
{% endif %}
|
||||
|
||||
{% ifversion code-scanning-task-lists %}
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[AUTOTITLE](/code-security/code-scanning/managing-code-scanning-alerts/tracking-code-scanning-alerts-in-issues-using-task-lists)"{% endif %}
|
||||
|
||||
@@ -106,6 +106,7 @@ You can create multiple tasklists in a single issue. Each tasklist has its own t
|
||||
- [ ] Draft task
|
||||
```
|
||||
````
|
||||
|
||||
1. To change the title of this tasklist, type a new title after `### `. For example, change `### Tasks` to `### Backend changes`.
|
||||
|
||||
In the next two sections, we will make further changes to the Markdown before saving the comment.
|
||||
|
||||
@@ -22,15 +22,20 @@ The projects you have marked as templates are made available in the "Select a te
|
||||
When someone creates a project from a template, the {% data reusables.projects.what-gets-copied %} are copied from the template to the new project. {% ifversion projects-v2-org-templates-improvements %}You can find the template that a project used from the project's settings page, under the "Templates" section.{% endif %}
|
||||
|
||||
{% ifversion projects-v2-org-templates-improvements %}
|
||||
|
||||
## Creating templates
|
||||
|
||||
{% else %}
|
||||
|
||||
## Setting a project as a template
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% ifversion projects-v2-org-templates-improvements %}
|
||||
You can either create a new template directly, or you can set a project as a template.
|
||||
|
||||
### Creating a new template
|
||||
|
||||
{% data reusables.profile.access_org %}
|
||||
{% data reusables.user-settings.access_org %}
|
||||
{% data reusables.projects.projects-tab %}
|
||||
@@ -38,6 +43,7 @@ You can either create a new template directly, or you can set a project as a tem
|
||||
1. Click **New template**.
|
||||
|
||||
### Setting a project as a template
|
||||
|
||||
{% endif %}
|
||||
If you have admin permissions for a project in your organization, you can set the project as a template and make it available for others in your organization to use.
|
||||
|
||||
|
||||
@@ -76,6 +76,7 @@ Here is an example of an issue created for a large initiative, front-end work, i
|
||||

|
||||
|
||||
{% ifversion task-lists-v1 %}
|
||||
|
||||
### Task list example
|
||||
|
||||
You can use task lists to break larger issues down into smaller tasks and to track issues as part of a larger goal. {% ifversion fpt or ghec %} Task lists have additional functionality when added to the body of an issue. You can see the number of tasks completed out of the total at the top of the issue, and if someone closes an issue linked in the task list, the checkbox will automatically be marked as complete.{% endif %} For more information, see "[AUTOTITLE](/get-started/writing-on-github/working-with-advanced-formatting/about-task-lists)."
|
||||
|
||||
@@ -41,6 +41,7 @@ You can use markdown to add formatting, links, emojis, and more. For more inform
|
||||

|
||||
|
||||
{% ifversion task-lists-v1 %}
|
||||
|
||||
## Adding a task list
|
||||
|
||||
It can be helpful to break large issues into smaller tasks, or to track multiple related issues in a single larger issue. Add a task list to your issue by prefacing list items with `[ ]`. Reference existing issues by issue number or URL. You can use plain text to track tasks that don't have a corresponding issue and convert them to issues later. For more information, see "[AUTOTITLE](/get-started/writing-on-github/working-with-advanced-formatting/about-task-lists)."
|
||||
|
||||
@@ -40,6 +40,7 @@ You can use the command line to import source code and, if the code has been tra
|
||||
All of these tools import source code and revision history, only. If you also want to import your settings and your collaboration history, such as issues and pull requests, you'll need to use more advanced tools. To determine the best tool to use for your migration, see "[AUTOTITLE](/migrations/overview/planning-your-migration-to-github)."
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[AUTOTITLE](/get-started/using-git/troubleshooting-the-2-gb-push-limit)"
|
||||
|
||||
@@ -62,6 +62,7 @@ To follow these steps, you must use a macOS or Linux system and have the followi
|
||||
{% data reusables.migrations.push-to-github %}
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[AUTOTITLE](/get-started/using-git/troubleshooting-the-2-gb-push-limit)"
|
||||
|
||||
@@ -58,6 +58,7 @@ To follow these steps, you must use a macOS or Linux system and have the followi
|
||||
{% data reusables.migrations.push-to-github %}
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[AUTOTITLE](/get-started/using-git/troubleshooting-the-2-gb-push-limit)"
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user