1
0
mirror of synced 2025-12-19 18:10:59 -05:00

Add disclaimer + improve security for third party actions (#20227)

This commit is contained in:
Sarah Edwards
2021-07-01 09:00:58 -07:00
committed by GitHub
parent cdf6baa86f
commit bedc6371af
22 changed files with 158 additions and 131 deletions

View File

@@ -16,6 +16,7 @@ topics:
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
{% data reusables.actions.ae-self-hosted-runners-notice %}
{% data reusables.actions.actions-not-certified-by-github-note %}
## Introduction
@@ -30,6 +31,8 @@ In the tutorial, you will first make a workflow file that uses the [`andymckay/l
3. Copy the following YAML contents into your workflow file.
```yaml{:copy}
{% indented_data_reference reusables.actions.actions-not-certified-by-github-comment spaces=4 %}
name: Label issues
on:
issues:
@@ -43,7 +46,7 @@ In the tutorial, you will first make a workflow file that uses the [`andymckay/l
issues: write{% endif %}
steps:
- name: Label issues
uses: andymckay/labeler@1.0.2
uses: andymckay/labeler@5c59dabdfd4dd5bd9c6e6d255b01b9d764af4414
with:
add-labels: "triage"
repo-token: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}

View File

@@ -19,6 +19,7 @@ shortTitle: Build & test Java & Gradle
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
{% data reusables.actions.actions-not-certified-by-github-note %}
## Introduction
@@ -47,8 +48,9 @@ To get started quickly, you can choose the preconfigured Gradle template when yo
You can also add this workflow manually by creating a new file in the `.github/workflows` directory of your repository.
{% raw %}
```yaml{:copy}
{% data reusables.actions.actions-not-certified-by-github-comment %}
name: Java CI
on: [push]
@@ -65,11 +67,10 @@ jobs:
java-version: '11'
distribution: 'adopt'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@v1
uses: gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
- name: Build with Gradle
run: ./gradlew build
```
{% endraw %}
This workflow performs the following steps:
@@ -101,7 +102,7 @@ steps:
java-version: '11'
distribution: 'adopt'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@v1
uses: gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
- name: Run the Gradle package task
run: ./gradlew -b ci.gradle package
```
@@ -121,7 +122,7 @@ steps:
java-version: '11'
distribution: 'adopt'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@v1
uses: gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
- name: Cache Gradle packages
uses: actions/cache@v2
with:
@@ -159,7 +160,7 @@ steps:
java-version: '11'
distribution: 'adopt'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@v1
uses: gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
- run: ./gradlew build
- uses: actions/upload-artifact@v2
with:

View File

@@ -18,6 +18,7 @@ shortTitle: Build & test Python
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
{% data reusables.actions.actions-not-certified-by-github-note %}
## Introduction
@@ -402,12 +403,8 @@ You can configure your workflow to publish your Python package to a package regi
For this example, you will need to create two [PyPI API tokens](https://pypi.org/help/#apitoken). You can use secrets to store the access tokens or credentials needed to publish your package. For more information, see "[Creating and using encrypted secrets](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
{% raw %}
```yaml{:copy}
# This workflow uses actions that are not certified by GitHub.
# They are provided by a third-party and are governed by
# separate terms of service, privacy policy, and support
# documentation.
{% data reusables.actions.actions-not-certified-by-github-comment %}
name: Upload Python Package
@@ -434,8 +431,7 @@ jobs:
uses: pypa/gh-action-pypi-publish@27b31702a0e7fc50959f5ad993c78deac1bdfc29
with:
user: __token__
password: ${{ secrets.PYPI_API_TOKEN }}
password: {% raw %}${{ secrets.PYPI_API_TOKEN }}{% endraw %}
```
{% endraw %}
For more information about the template workflow, see [`python-publish`](https://github.com/actions/starter-workflows/blob/main/ci/python-publish.yml).

View File

@@ -15,6 +15,7 @@ topics:
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
{% data reusables.actions.actions-not-certified-by-github-note %}
## Introduction
@@ -33,8 +34,9 @@ We recommend that you have a basic understanding of Ruby, YAML, workflow configu
To get started quickly, add the template to the `.github/workflows` directory of your repository. The workflow shown below assumes that the default branch for your repository is `main`.
{% raw %}
```yaml
{% data reusables.actions.actions-not-certified-by-github-comment %}
name: Ruby
on:
@@ -51,7 +53,7 @@ jobs:
steps:
- uses: actions/checkout@v2
- name: Set up Ruby
uses: ruby/setup-ruby@v1
uses: ruby/setup-ruby@477b21f02be01bcb8030d50f37cfec92bfa615b6
with:
ruby-version: 2.6
- name: Install dependencies
@@ -59,7 +61,6 @@ jobs:
- name: Run tests
run: bundle exec rake
```
{% endraw %}
## Specifying the Ruby version
@@ -73,7 +74,7 @@ The `setup-ruby` action takes a Ruby version as an input and configures that ver
```yaml
steps:
- uses: actions/checkout@v2
- uses: ruby/setup-ruby@v1
- uses: ruby/setup-ruby@477b21f02be01bcb8030d50f37cfec92bfa615b6
with:
ruby-version: 2.6 # Not needed with a .ruby-version file
- run: bundle install
@@ -99,8 +100,9 @@ Each version of Ruby specified in the `ruby-version` array creates a job that ru
The full updated workflow with a matrix strategy could look like this:
{% raw %}
```yaml
{% data reusables.actions.actions-not-certified-by-github-comment %}
name: Ruby CI
on:
@@ -120,16 +122,15 @@ jobs:
steps:
- uses: actions/checkout@v2
- name: Set up Ruby ${{ matrix.ruby-version }}
uses: ruby/setup-ruby@v1
- name: {% raw %}Set up Ruby ${{ matrix.ruby-version }}{% endraw %}
uses: ruby/setup-ruby@477b21f02be01bcb8030d50f37cfec92bfa615b6
with:
ruby-version: ${{ matrix.ruby-version }}
ruby-version: {% raw %}${{ matrix.ruby-version }}{% endraw %}
- name: Install dependencies
run: bundle install
- name: Run tests
run: bundle exec rake
```
{% endraw %}
## Installing dependencies with Bundler
@@ -139,7 +140,7 @@ The `setup-ruby` action will automatically install bundler for you. The version
```yaml
steps:
- uses: actions/checkout@v2
- uses: ruby/setup-ruby@v1
- uses: ruby/setup-ruby@477b21f02be01bcb8030d50f37cfec92bfa615b6
with:
ruby-version: 2.6
- run: bundle install
@@ -155,7 +156,7 @@ To enable caching, set the following.
{% raw %}
```yaml
steps:
- uses: ruby/setup-ruby@v1
- uses: ruby/setup-ruby@477b21f02be01bcb8030d50f37cfec92bfa615b6
with:
bundler-cache: true
```
@@ -205,8 +206,9 @@ steps:
The following example matrix tests all stable releases and head versions of MRI, JRuby and TruffleRuby on Ubuntu and macOS.
{% raw %}
```yaml
{% data reusables.actions.actions-not-certified-by-github-comment %}
name: Matrix Testing
on:
@@ -217,29 +219,29 @@ on:
jobs:
test:
runs-on: ${{ matrix.os }}-latest
runs-on: {% raw %}${{ matrix.os }}-latest{% endraw %}
strategy:
fail-fast: false
matrix:
os: [ubuntu, macos]
ruby: [2.5, 2.6, 2.7, head, debug, jruby, jruby-head, truffleruby, truffleruby-head]
continue-on-error: ${{ endsWith(matrix.ruby, 'head') || matrix.ruby == 'debug' }}
continue-on-error: {% raw %}${{ endsWith(matrix.ruby, 'head') || matrix.ruby == 'debug' }}{% endraw %}
steps:
- uses: actions/checkout@v2
- uses: ruby/setup-ruby@v1
- uses: ruby/setup-ruby@477b21f02be01bcb8030d50f37cfec92bfa615b6
with:
ruby-version: ${{ matrix.ruby }}
ruby-version: {% raw %}${{ matrix.ruby }}{% endraw %}
- run: bundle install
- run: bundle exec rake
```
{% endraw %}
## Linting your code
The following example installs `rubocop` and uses it to lint all files. For more information, see [Rubocop](https://github.com/rubocop-hq/rubocop). You can [configure Rubocop](https://docs.rubocop.org/rubocop/configuration.html) to decide on the specific linting rules.
{% raw %}
```yaml
{% data reusables.actions.actions-not-certified-by-github-comment %}
name: Linting
on: [push]
@@ -249,14 +251,13 @@ jobs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: ruby/setup-ruby@v1
- uses: ruby/setup-ruby@477b21f02be01bcb8030d50f37cfec92bfa615b6
with:
ruby-version: 2.6
- run: bundle install
- name: Rubocop
run: rubocop
```
{% endraw %}
## Publishing Gems
@@ -265,6 +266,7 @@ You can configure your workflow to publish your Ruby package to any package regi
You can store any access tokens or credentials needed to publish your package using repository secrets. The following example creates and publishes a package to `GitHub Package Registry` and `RubyGems`.
```yaml
{% data reusables.actions.actions-not-certified-by-github-comment %}
name: Ruby Gem
@@ -288,7 +290,7 @@ jobs:
steps:{% raw %}
- uses: actions/checkout@v2
- name: Set up Ruby 2.6
uses: ruby/setup-ruby@v1
uses: ruby/setup-ruby@477b21f02be01bcb8030d50f37cfec92bfa615b6
with:
ruby-version: 2.6
- run: bundle install

View File

@@ -16,6 +16,7 @@ shortTitle: Build & test Swift
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
{% data reusables.actions.actions-not-certified-by-github-note %}
## Introduction
@@ -68,31 +69,31 @@ The examples below demonstrate using the `fwal/setup-swift` action.
You can configure your job to use a multiple versions of Swift in a build matrix.
{% raw %}
```yaml{:copy}
{% data reusables.actions.actions-not-certified-by-github-comment %}
name: Swift
on: [push]
jobs:
build:
name: Swift ${{ matrix.swift }} on ${{ matrix.os }}
name: {% raw %}Swift ${{ matrix.swift }} on ${{ matrix.os }}{% endraw %}
strategy:
matrix:
os: [ubuntu-latest, macos-latest]
swift: ["5.2", "5.3"]
runs-on: ${{ matrix.os }}
runs-on: {% raw %}${{ matrix.os }}{% endraw %}
steps:
- uses: fwal/setup-swift@v1
- uses: fwal/setup-swift@d43a564349d1341cd990cfbd70d94d63b8899475
with:
swift-version: ${{ matrix.swift }}
- uses: actions/checkout@v2
swift-version: {% raw %}${{ matrix.swift }}{% endraw %}
- uses: actions/checkout@
- name: Build
run: swift build
- name: Run tests
run: swift test
```
{% endraw %}
### Using a single specific Swift version
@@ -101,7 +102,7 @@ You can configure your job to use a single specific version of Swift, such as `5
{% raw %}
```yaml{:copy}
steps:
- uses: fwal/setup-swift@v1
- uses: fwal/setup-swift@d43a564349d1341cd990cfbd70d94d63b8899475
with:
swift-version: "5.3.3"
- name: Get swift version
@@ -117,7 +118,7 @@ You can use the same commands that you use locally to build and test your code u
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: fwal/setup-swift@v1
- uses: fwal/setup-swift@d43a564349d1341cd990cfbd70d94d63b8899475
with:
swift-version: "5.3.3"
- name: Build

View File

@@ -17,6 +17,7 @@ shortTitle: Add label to comment on issue
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
{% data reusables.actions.ae-self-hosted-runners-notice %}
{% data reusables.actions.actions-not-certified-by-github-note %}
## Introduction
@@ -31,6 +32,8 @@ In the tutorial, you will first make a workflow file that uses the [`peter-evans
3. Copy the following YAML contents into your workflow file.
```yaml{:copy}
{% indented_data_reference reusables.actions.actions-not-certified-by-github-comment spaces=4 %}
name: Add comment
on:
issues:
@@ -44,7 +47,7 @@ In the tutorial, you will first make a workflow file that uses the [`peter-evans
issues: write{% endif %}
steps:
- name: Add comment
uses: peter-evans/create-or-update-comment@v1
uses: peter-evans/create-or-update-comment@a35cf36e5301d70b76f316e867e7788a55a31dae
with:
issue-number: {% raw %}${{ github.event.issue.number }}{% endraw %}
body: |

View File

@@ -17,6 +17,7 @@ shortTitle: Deploy to Amazon ECS
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
{% data reusables.actions.actions-not-certified-by-github-note %}
## Introduction
@@ -75,6 +76,8 @@ The following example workflow demonstrates how to build a container image and p
Ensure that you provide your own values for all the variables in the `env` key of the workflow.
```yaml{:copy}
{% data reusables.actions.actions-not-certified-by-github-comment %}
name: Deploy to Amazon ECS
on:
@@ -108,7 +111,7 @@ jobs:
uses: actions/checkout@v2
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v1
uses: aws-actions/configure-aws-credentials@13d241b293754004c80624b5567555c4a39ffbe3
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
@@ -116,7 +119,7 @@ jobs:
- name: Login to Amazon ECR
id: login-ecr
uses: aws-actions/amazon-ecr-login@v1
uses: aws-actions/amazon-ecr-login@aaf69d68aa3fb14c1d5a6be9ac61fe15b48453a2
- name: Build, tag, and push image to Amazon ECR
id: build-image
@@ -133,14 +136,14 @@ jobs:
- name: Fill in the new image ID in the Amazon ECS task definition
id: task-def
uses: aws-actions/amazon-ecs-render-task-definition@v1
uses: aws-actions/amazon-ecs-render-task-definition@97587c9d45a4930bf0e3da8dd2feb2a463cf4a3a
with:
task-definition: ${{ env.ECS_TASK_DEFINITION }}
container-name: ${{ env.CONTAINER_NAME }}
image: ${{ steps.build-image.outputs.image }}
- name: Deploy Amazon ECS task definition
uses: aws-actions/amazon-ecs-deploy-task-definition@v1
uses: aws-actions/amazon-ecs-deploy-task-definition@de0132cf8cdedb79975c6d42b77eb7ea193cf28e
with:
task-definition: ${{ steps.task-def.outputs.task-definition }}
service: ${{ env.ECS_SERVICE }}

View File

@@ -17,6 +17,7 @@ shortTitle: Deploy to Azure App Service
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
{% data reusables.actions.actions-not-certified-by-github-note %}
## Introduction
@@ -74,8 +75,9 @@ The following example workflow demonstrates how to build, test, and deploy the N
Ensure that you set `AZURE_WEBAPP_NAME` in the workflow `env` key to the name of the web app you created.
{% raw %}
```yaml{:copy}
{% data reusables.actions.actions-not-certified-by-github-comment %}
on:
release:
types: [created]
@@ -92,10 +94,10 @@ jobs:
steps:
- uses: actions/checkout@v2
- name: Use Node.js ${{ env.NODE_VERSION }}
- name: Use Node.js {% raw %}${{ env.NODE_VERSION }}{% endraw %}
uses: actions/setup-node@v2
with:
node-version: ${{ env.NODE_VERSION }}
node-version: {% raw %}${{ env.NODE_VERSION }}{% endraw %}
- name: npm install, build, and test
run: |
@@ -106,13 +108,12 @@ jobs:
npm run test --if-present
- name: 'Deploy to Azure WebApp'
uses: azure/webapps-deploy@v2
uses: azure/webapps-deploy@0b651ed7546ecfc75024011f76944cb9b381ef1e
with:
app-name: ${{ env.AZURE_WEBAPP_NAME }}
publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}
app-name: {% raw %}${{ env.AZURE_WEBAPP_NAME }}{% endraw %}
publish-profile: {% raw %}${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}{% endraw %}
package: {% raw %}${{ env.AZURE_WEBAPP_PACKAGE_PATH }}{% endraw %}
```
{% endraw %}
## Additional resources

View File

@@ -17,6 +17,7 @@ shortTitle: Deploy to Kubernetes (GKE)
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
{% data reusables.actions.actions-not-certified-by-github-note %}
## Introduction
@@ -104,8 +105,9 @@ Once you've completed the prerequisites, you can proceed with creating the workf
The following example workflow demonstrates how to build a container image and push it to GCR. It then uses the Kubernetes tools (such as `kubectl` and `kustomize`) to pull the image into the cluster deployment.
{% raw %}
```yaml{:copy}
{% data reusables.actions.actions-not-certified-by-github-comment %}
name: Build and Deploy to GKE
on:
@@ -113,7 +115,7 @@ on:
types: [created]
env:
PROJECT_ID: ${{ secrets.GKE_PROJECT }}
PROJECT_ID: {% raw %}${{ secrets.GKE_PROJECT }}{% endraw %}
GKE_CLUSTER: cluster-1 # Add your cluster name here.
GKE_ZONE: us-central1-c # Add your cluster zone here.
DEPLOYMENT_NAME: gke-test # Add your deployment name here.
@@ -129,21 +131,21 @@ jobs:
uses: actions/checkout@v2
# Setup gcloud CLI
- uses: google-github-actions/setup-gcloud@v0.2.0
- uses: google-github-actions/setup-gcloud@94337306dda8180d967a56932ceb4ddcf01edae7
with:
service_account_key: ${{ secrets.GKE_SA_KEY }}
project_id: ${{ secrets.GKE_PROJECT }}
service_account_key: {% raw %}${{ secrets.GKE_SA_KEY }}{% endraw %}
project_id: {% raw %}${{ secrets.GKE_PROJECT }}{% endraw %}
# Configure docker to use the gcloud command-line tool as a credential helper
- run: |-
gcloud --quiet auth configure-docker
# Get the GKE credentials so we can deploy to the cluster
- uses: google-github-actions/get-gke-credentials@v0.2.1
- uses: google-github-actions/get-gke-credentials@fb08709ba27618c31c09e014e1d8364b02e5042e
with:
cluster_name: ${{ env.GKE_CLUSTER }}
location: ${{ env.GKE_ZONE }}
credentials: ${{ secrets.GKE_SA_KEY }}
cluster_name: {% raw %}${{ env.GKE_CLUSTER }}{% endraw %}
location: {% raw %}${{ env.GKE_ZONE }}{% endraw %}
credentials: {% raw %}${{ secrets.GKE_SA_KEY }}{% endraw %}
# Build the Docker image
- name: Build
@@ -173,7 +175,6 @@ jobs:
kubectl rollout status deployment/$DEPLOYMENT_NAME
kubectl get services -o wide
```
{% endraw %}
## Additional resources

View File

@@ -17,6 +17,7 @@ shortTitle: Move assigned issues
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
{% data reusables.actions.ae-self-hosted-runners-notice %}
{% data reusables.actions.actions-not-certified-by-github-note %}
## Introduction
@@ -31,8 +32,9 @@ In the tutorial, you will first make a workflow file that uses the [`alex-page/g
3. {% data reusables.actions.make-workflow-file %}
4. Copy the following YAML contents into your workflow file.
{% raw %}
```yaml{:copy}
{% indented_data_reference reusables.actions.actions-not-certified-by-github-comment spaces=4 %}
name: Move assigned card
on:
issues:
@@ -42,13 +44,13 @@ In the tutorial, you will first make a workflow file that uses the [`alex-page/g
move-assigned-card:
runs-on: ubuntu-latest
steps:
- uses: alex-page/github-project-automation-plus@v0.3.0
- uses: alex-page/github-project-automation-plus@5bcba1c1c091a222584d10913e5c060d32c44044
with:
project: Docs Work
column: In Progress
repo-token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
repo-token: {% raw %}${{ secrets.PERSONAL_ACCESS_TOKEN }}{% endraw %}
```
{% endraw %}
5. Customize the parameters in your workflow file:
- Change the value for `project` to the name of your project board. If you have multiple project boards with the same name, the `alex-page/github-project-automation-plus` action will act on all projects with the specified name.
- Change the value for `column` to the name of the column where you want issues to move when they are assigned.

View File

@@ -18,6 +18,7 @@ topics:
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
{% data reusables.actions.actions-not-certified-by-github-note %}
## Introduction
@@ -67,9 +68,9 @@ The `build-push-action` options required for Docker Hub are:
* `push`: If set to `true`, the image will be pushed to the registry if it is built successfully.
```yaml{:copy}
name: Publish Docker image
{% data reusables.actions.actions-not-certified-by-github-comment %}
{% data reusables.actions.actions-not-certified-by-github %}
name: Publish Docker image
on:
release:
@@ -84,19 +85,19 @@ jobs:
uses: actions/checkout@v2
- name: Log in to Docker Hub
uses: docker/login-action@v1
uses: docker/login-action@f054a8b539a109f9f41c372932f1ae047eff08c9
with:
username: {% raw %}${{ secrets.DOCKER_USERNAME }}{% endraw %}
password: {% raw %}${{ secrets.DOCKER_PASSWORD }}{% endraw %}
- name: Extract metadata (tags, labels) for Docker
id: meta
uses: docker/metadata-action@v3
uses: docker/metadata-action@98669ae865ea3cffbcbaa878cf57c20bbf1c6c38
with:
images: my-docker-hub-namespace/my-docker-hub-repository
- name: Build and push Docker image
uses: docker/build-push-action@v2
uses: docker/build-push-action@ad44023a93711e3deb337508980b4b5e9bcdc5dc
with:
context: .
push: true
@@ -135,9 +136,9 @@ The above workflow if triggered by a push to the "release" branch. It checks out
{% else %}
```yaml{:copy}
name: Publish Docker image
{% data reusables.actions.actions-not-certified-by-github-comment %}
{% data reusables.actions.actions-not-certified-by-github %}
name: Publish Docker image
on:
release:
@@ -154,14 +155,14 @@ jobs:
uses: actions/checkout@v2
- name: Log in to GitHub Docker Registry
uses: docker/login-action@v1
uses: docker/login-action@f054a8b539a109f9f41c372932f1ae047eff08c9
with:
registry: {% ifversion ghae %}docker.YOUR-HOSTNAME.com{% else %}docker.pkg.github.com{% endif %}
username: {% raw %}${{ github.actor }}{% endraw %}
password: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
- name: Build and push Docker image
uses: docker/build-push-action@v2
uses: docker/build-push-action@ad44023a93711e3deb337508980b4b5e9bcdc5dc
with:
context: .
push: true
@@ -179,12 +180,10 @@ In a single workflow, you can publish your Docker image to multiple registries b
The following example workflow uses the steps from the previous sections ("[Publishing images to Docker Hub](#publishing-images-to-docker-hub)" and "[Publishing images to {% data variables.product.prodname_registry %}](#publishing-images-to-github-packages)") to create a single workflow that pushes to both registries.
```yaml{:copy}
name: Publish Docker image
{% data reusables.actions.actions-not-certified-by-github-comment %}
{% data reusables.actions.actions-not-certified-by-github %}
name: Publish Docker image
on:
release:
@@ -202,13 +201,13 @@ jobs:
uses: actions/checkout@v2
- name: Log in to Docker Hub
uses: docker/login-action@v1
uses: docker/login-action@f054a8b539a109f9f41c372932f1ae047eff08c9
with:
username: {% raw %}${{ secrets.DOCKER_USERNAME }}{% endraw %}
password: {% raw %}${{ secrets.DOCKER_PASSWORD }}{% endraw %}
- name: Log in to the {% ifversion fpt %}Container{% else %}Docker{% endif %} registry
uses: docker/login-action@v1
uses: docker/login-action@f054a8b539a109f9f41c372932f1ae047eff08c9
with:
registry: {% ifversion fpt %}ghcr.io{% elsif ghae %}docker.YOUR-HOSTNAME.com{% else %}docker.pkg.github.com{% endif %}
username: {% raw %}${{ github.actor }}{% endraw %}
@@ -216,14 +215,14 @@ jobs:
- name: Extract metadata (tags, labels) for Docker
id: meta
uses: docker/metadata-action@v3
uses: docker/metadata-action@98669ae865ea3cffbcbaa878cf57c20bbf1c6c38
with:
images: |
my-docker-hub-namespace/my-docker-hub-repository
{% ifversion fpt %}ghcr.io/{% raw %}${{ github.repository }}{% endraw %}{% elsif ghae %}{% raw %}docker.YOUR-HOSTNAME.com/${{ github.repository }}/my-image{% endraw %}{% else %}{% raw %}docker.pkg.github.com/${{ github.repository }}/my-image{% endraw %}{% endif %}
- name: Build and push Docker images
uses: docker/build-push-action@v2
uses: docker/build-push-action@ad44023a93711e3deb337508980b4b5e9bcdc5dc
with:
context: .
push: true

View File

@@ -20,6 +20,7 @@ shortTitle: Java packages with Gradle
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
{% data reusables.actions.actions-not-certified-by-github-note %}
## Introduction
@@ -78,9 +79,9 @@ With this configuration, you can create a workflow that publishes your package t
In the deploy step, youll need to set environment variables for the username and password or token that you use to authenticate to the Maven repository. For more information, see "[Creating and using encrypted secrets](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
{% raw %}
```yaml{:copy}
{% data reusables.actions.actions-not-certified-by-github-comment %}
name: Publish package to the Maven Central Repository
on:
release:
@@ -96,14 +97,13 @@ jobs:
java-version: '11'
distribution: 'adopt'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@v1
uses: gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
- name: Publish package
run: gradle publish
env:
MAVEN_USERNAME: ${{ secrets.OSSRH_USERNAME }}
MAVEN_PASSWORD: ${{ secrets.OSSRH_TOKEN }}
MAVEN_USERNAME: {% raw %}${{ secrets.OSSRH_USERNAME }}{% endraw %}
MAVEN_PASSWORD: {% raw %}${{ secrets.OSSRH_TOKEN }}{% endraw %}
```
{% endraw %}
{% data reusables.github-actions.gradle-workflow-steps %}
1. Runs the `gradle publish` command to publish to the `OSSRH` Maven repository. The `MAVEN_USERNAME` environment variable will be set with the contents of your `OSSRH_USERNAME` secret, and the `MAVEN_PASSWORD` environment variable will be set with the contents of your `OSSRH_TOKEN` secret.
@@ -147,6 +147,8 @@ publishing {
With this configuration, you can create a workflow that publishes your package to the Maven Central Repository by running the `gradle publish` command.
```yaml{:copy}
{% data reusables.actions.actions-not-certified-by-github-comment %}
name: Publish package to GitHub Packages
on:
release:
@@ -164,7 +166,7 @@ jobs:
java-version: '11'
distribution: 'adopt'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@v1
uses: gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
- name: Publish package
run: gradle publish
env:
@@ -221,6 +223,8 @@ publishing {
With this configuration, you can create a workflow that publishes your package to both the Maven Central Repository and {% data variables.product.prodname_registry %} by running the `gradle publish` command.
```yaml{:copy}
{% data reusables.actions.actions-not-certified-by-github-comment %}
name: Publish package to the Maven Central Repository and GitHub Packages
on:
release:
@@ -239,7 +243,7 @@ jobs:
java-version: '11'
distribution: 'adopt'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@v1
uses: gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
- name: Publish to the Maven Central Repository
run: gradle publish
env: {% raw %}

View File

@@ -17,6 +17,7 @@ shortTitle: Remove label when adding card
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
{% data reusables.actions.ae-self-hosted-runners-notice %}
{% data reusables.actions.actions-not-certified-by-github-note %}
## Introduction
@@ -32,6 +33,8 @@ In the tutorial, you will first make a workflow file that uses the [`andymckay/l
4. Copy the following YAML contents into your workflow file.
```yaml{:copy}
{% indented_data_reference reusables.actions.actions-not-certified-by-github-comment spaces=4 %}
name: Remove labels
on:
project_card:
@@ -46,7 +49,7 @@ In the tutorial, you will first make a workflow file that uses the [`andymckay/l
pull-requests: write{% endif %}
steps:
- name: remove labels
uses: andymckay/labeler@master
uses: andymckay/labeler@5c59dabdfd4dd5bd9c6e6d255b01b9d764af4414
with:
remove-labels: "needs review"
repo-token: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}

View File

@@ -16,6 +16,7 @@ topics:
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
{% data reusables.actions.ae-self-hosted-runners-notice %}
{% data reusables.actions.actions-not-certified-by-github-note %}
## Introduction
@@ -30,6 +31,8 @@ In the tutorial, you will first make a workflow file that uses the [`imjohnbo/is
3. Copy the following YAML contents into your workflow file.
```yaml{:copy}
{% indented_data_reference reusables.actions.actions-not-certified-by-github-comment spaces=4 %}
name: Weekly Team Sync
on:
schedule:
@@ -43,7 +46,7 @@ In the tutorial, you will first make a workflow file that uses the [`imjohnbo/is
issues: write{% endif %}
steps:
- name: Create team sync issue
uses: imjohnbo/issue-bot@v3.0
uses: imjohnbo/issue-bot@3daae12aa54d38685d7ff8459fc8a2aee8cea98b
with:
assignees: "monalisa, doctocat, hubot"
labels: "weekly sync, docs-team"

View File

@@ -19,6 +19,7 @@ shortTitle: Migrate from CircleCI
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
{% data reusables.actions.actions-not-certified-by-github-note %}
## Introduction
@@ -402,6 +403,8 @@ workflows:
<td class="d-table-cell v-align-top">
{% raw %}
```yaml
{% endraw %}{% data reusables.actions.actions-not-certified-by-github-comment %}{% raw %}
name: Containers
on: [push]
@@ -435,7 +438,7 @@ jobs:
steps:
- uses: actions/checkout@v2
- name: Setup Ruby
uses: eregon/use-ruby-action@master
uses: eregon/use-ruby-action@477b21f02be01bcb8030d50f37cfec92bfa615b6
with:
ruby-version: ${{ matrix.ruby }}
- name: Cache dependencies

View File

@@ -595,7 +595,7 @@ The `my backup step` only runs when the previous step of a job fails. For more i
```yaml
steps:
- name: My first step
uses: monacorp/action-name@main
uses: octo-org/action-name@main
- name: My backup step
if: {% raw %}${{ failure() }}{% endraw %}
uses: actions/heroku@1.0.0
@@ -644,7 +644,7 @@ jobs:
steps:
- name: My first step
# Uses the default branch of a public repository
uses: actions/heroku@1.0.0
uses: actions/heroku@main
- name: My second step
# Uses a specific version tag of a public repository
uses: actions/aws@v2.0.1
@@ -909,7 +909,7 @@ A `string` that defines the inputs for a Docker container. {% data variables.pro
```yaml
steps:
- name: Explain why this job ran
uses: monacorp/action-name@main
uses: octo-org/action-name@main
with:
entrypoint: /bin/echo
args: The ${{ github.event_name }} event triggered this step.
@@ -931,7 +931,7 @@ Overrides the Docker `ENTRYPOINT` in the `Dockerfile`, or sets it if one wasn't
```yaml
steps:
- name: Run a custom command
uses: monacorp/action-name@main
uses: octo-org/action-name@main
with:
entrypoint: /a/different/executable
```

View File

@@ -66,7 +66,7 @@ This example demonstrates using the `actions-sync` tool to sync an individual ac
--cache-dir "cache" \
--destination-token "aabbccddeeffgg" \
--destination-url "https://my-ghes-instance" \
--repo-name "docker/build-push-action:synced-actions/docker-build-push-action"
--repo-name "actions/stale:synced-actions/actions-stale"
```
The above command uses the following arguments:
@@ -76,13 +76,13 @@ This example demonstrates using the `actions-sync` tool to sync an individual ac
* `--destination-url`: The URL of the destination enterprise instance.
* `--repo-name`: The action repository to sync. This takes the format of `owner/repository:destination_owner/destination_repository`.
* The above example syncs the [`docker/build-push-action`](https://github.com/docker/build-push-action) repository to the `synced-actions/docker-build-push-action` repository on the destination enterprise instance. You must create the organization named `synced-actions` in your enterprise before running the above command.
* The above example syncs the [`actions/stale`](https://github.com/actions/stale) repository to the `synced-actions/actions-stale` repository on the destination enterprise instance. You must create the organization named `synced-actions` in your enterprise before running the above command.
* If you omit `:destination_owner/destination_repository`, the tool uses the original owner and repository name for your enterprise. Before running the command, you must create a new organization in your enterprise that matches the owner name of the action. Consider using a central organization to store the synced actions in your enterprise, as this means you will not need to create multiple new organizations if you sync actions from different owners.
* You can sync multiple actions by replacing the `--repo-name` parameter with `--repo-name-list` or `--repo-name-list-file`. For more information, see the [`actions-sync` README](https://github.com/actions/actions-sync#actions-sync).
1. After the action repository is created in your enterprise, people in your enterprise can use the destination repository to reference the action in their workflows. For the example action shown above:
```yaml
uses: synced-actions/docker-build-push-action@v1
uses: synced-actions/actions-stale@v1
```
For more information, see "[Workflow syntax for GitHub Actions](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsuses)."

View File

@@ -17,6 +17,7 @@ shortTitle: Publish & install with Actions
{% data reusables.package_registry.packages-ghae-release-stage %}
{% data reusables.actions.ae-beta %}
{% data reusables.actions.ae-self-hosted-runners-notice %}
{% data reusables.actions.actions-not-certified-by-github-note %}
## About {% data variables.product.prodname_registry %} with {% data variables.product.prodname_actions %}
@@ -93,7 +94,7 @@ Create a new workflow file in your repository (such as `.github/workflows/deploy
```yaml{:copy}
name: Create and publish a Docker image
{% data reusables.actions.actions-not-certified-by-github %}
{% data reusables.actions.actions-not-certified-by-github-comment %}
on:
push:
@@ -147,13 +148,13 @@ jobs:
- name: Checkout
uses: actions/checkout@v2
- name: Log in to GitHub Docker Registry
uses: docker/login-action@v1
uses: docker/login-action@f054a8b539a109f9f41c372932f1ae047eff08c9
with:
registry: {% ifversion ghae %}docker.YOUR-HOSTNAME.com{% else %}docker.pkg.github.com{% endif %}
username: {% raw %}${{ github.actor }}{% endraw %}
password: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
- name: Build and push Docker image
uses: docker/build-push-action@v2
uses: docker/build-push-action@ad44023a93711e3deb337508980b4b5e9bcdc5dc
with:
push: true
tags: |
@@ -312,7 +313,7 @@ permissions:
{% raw %}
```yaml
- name: Log in to the Container registry
uses: docker/login-action@v1
uses: docker/login-action@f054a8b539a109f9f41c372932f1ae047eff08c9
with:
registry: ${{ env.REGISTRY }}
username: ${{ github.actor }}
@@ -331,7 +332,7 @@ permissions:
```yaml
- name: Extract metadata (tags, labels) for Docker
id: meta
uses: docker/metadata-action@v3
uses: docker/metadata-action@98669ae865ea3cffbcbaa878cf57c20bbf1c6c38
with:
images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
```
@@ -348,7 +349,7 @@ permissions:
{% raw %}
```yaml
- name: Log in to GitHub Docker Registry
uses: docker/login-action@v1
uses: docker/login-action@f054a8b539a109f9f41c372932f1ae047eff08c9
with:
registry: {% endraw %}{% ifversion ghae %}docker.YOUR-HOSTNAME.com{% else %}docker.pkg.github.com{% endif %}{% raw %}
username: ${{ github.actor }}
@@ -379,7 +380,7 @@ permissions:
<td>
{% raw %}
```yaml
uses: docker/build-push-action@v2
uses: docker/build-push-action@ad44023a93711e3deb337508980b4b5e9bcdc5dc
```
{% endraw %}
</td>

View File

@@ -0,0 +1,5 @@
{% note %}
**Note:** Examples in this article use actions that are not certified by GitHub. The actions are provided by a third-party and are governed by separate terms of service, privacy policy, and support documentation.
{% endnote %}

View File

@@ -1 +1 @@
The configuration file can be located within the repository you are analyzing, or in an external repository. Using an external repository allows you to specify configuration options for multiple repositories in a single place. When you reference a configuration file located in an external repository, you can use the _OWNER/REPOSITORY/FILENAME@BRANCH_ syntax. For example, _monacorp/shared/codeql-config.yml@main_.
The configuration file can be located within the repository you are analyzing, or in an external repository. Using an external repository allows you to specify configuration options for multiple repositories in a single place. When you reference a configuration file located in an external repository, you can use the _OWNER/REPOSITORY/FILENAME@BRANCH_ syntax. For example, _octo-org/shared/codeql-config.yml@main_.

View File

@@ -1,11 +1,7 @@
{% raw %}
```yaml{:copy}
name: Create and publish a Docker image
{% data reusables.actions.actions-not-certified-by-github-comment %}
# This workflow uses actions that are not certified by GitHub.
# They are provided by a third-party and are governed by
# separate terms of service, privacy policy, and support
# documentation.
name: Create and publish a Docker image
on:
push:
@@ -13,7 +9,7 @@ on:
env:
REGISTRY: ghcr.io
IMAGE_NAME: ${{ github.repository }}
IMAGE_NAME: {% raw %}${{ github.repository }}{% endraw %}
jobs:
build-and-push-image:
@@ -27,24 +23,24 @@ jobs:
uses: actions/checkout@v2
- name: Log in to the Container registry
uses: docker/login-action@v1
uses: docker/login-action@f054a8b539a109f9f41c372932f1ae047eff08c9
with:
registry: ${{ env.REGISTRY }}
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
registry: {% raw %}${{ env.REGISTRY }}{% endraw %}
username: {% raw %}${{ github.actor }}{% endraw %}
password: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
- name: Extract metadata (tags, labels) for Docker
id: meta
uses: docker/metadata-action@v3
uses: docker/metadata-action@98669ae865ea3cffbcbaa878cf57c20bbf1c6c38
with:
images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
images: {% raw %}${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}{% raw %}
- name: Build and push Docker image
uses: docker/build-push-action@v2
uses: docker/build-push-action@ad44023a93711e3deb337508980b4b5e9bcdc5dc
with:
context: .
push: true
tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }}
tags: {% raw %}${{ steps.meta.outputs.tags }}{% endraw %}
labels: {% raw %}${{ steps.meta.outputs.labels }}{% endraw %}
```
{% endraw %}