Merge branch 'main' into repo-sync

content/actions/guides/adding-labels-to-issues.md

@@ -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 %}

content/actions/guides/building-and-testing-java-with-gradle.md

@@ -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:

content/actions/guides/building-and-testing-python.md

@@ -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).

content/actions/guides/building-and-testing-ruby.md

@@ -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

content/actions/guides/building-and-testing-swift.md

@@ -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

content/actions/guides/commenting-on-an-issue-when-a-label-is-added.md

@@ -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: |

content/actions/guides/deploying-to-amazon-elastic-container-service.md

@@ -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 }}

content/actions/guides/deploying-to-azure-app-service.md

@@ -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
 

content/actions/guides/deploying-to-google-kubernetes-engine.md

@@ -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
 

content/actions/guides/moving-assigned-issues-on-project-boards.md

@@ -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.

content/actions/guides/publishing-docker-images.md

@@ -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

content/actions/guides/publishing-java-packages-with-gradle.md

@@ -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, you’ll 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 %}

content/actions/guides/removing-a-label-when-a-card-is-added-to-a-project-board-column.md

@@ -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 %}

content/actions/guides/scheduling-issue-creation.md

@@ -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"

content/actions/learn-github-actions/migrating-from-circleci-to-github-actions.md

@@ -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

content/actions/reference/workflow-syntax-for-github-actions.md

@@ -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
 ```

content/admin/github-actions/managing-access-to-actions-from-githubcom/manually-syncing-actions-from-githubcom.md

@@ -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)."

content/issues/index.md

@@ -11,6 +11,7 @@ featuredLinks:
     - /issues/trying-out-the-new-projects-experience/quickstart
     - /issues/trying-out-the-new-projects-experience/best-practices-for-managing-projects
     - /communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository
+    - /issues/tracking-your-work-with-issues/planning-and-tracking-work-for-your-team-or-project
   guideCards:
     - /issues/trying-out-the-new-projects-experience/automating-projects
     - /issues/tracking-your-work-with-issues/creating-issues/linking-a-pull-request-to-an-issue

content/issues/tracking-your-work-with-issues/index.md

@@ -20,6 +20,7 @@ children:
   - /pinning-an-issue-to-your-repository
   - /transferring-an-issue-to-another-repository
   - /deleting-an-issue
+  - /planning-and-tracking-work-for-your-team-or-project
 redirect_from:
   - /issues/tracking-your-work-with-issues/creating-issues
   - /issues/tracking-your-work-with-issues/managing-issues

content/issues/tracking-your-work-with-issues/planning-and-tracking-work-for-your-team-or-project.md

@@ -0,0 +1,116 @@
+---
+title: Planning and tracking work for your team or project
+intro: "The essentials for using {% data variables.product.prodname_dotcom %}'s planning and tracking tools to manage work on a team or project."
+versions:
+  fpt: '*'
+  ghes: '*'
+  ghae: '*'
+---
+## Introduction
+You can use {% data variables.product.prodname_dotcom %} repositories, issues, project boards, and other tools to plan and track your work, whether working on an individual project or cross-functional team.
+
+In this guide, you will learn how to create and set up a repository for collaborating with a group of people, create issue templates{% ifversion fpt %} and forms{% endif %}, open issues and use task lists to break down work, and establish a project board for organizing and tracking issues.
+
+## Creating a repository
+When starting a new project, initiative, or feature, the first step is to create a repository. Repositories contain all of your project's files and give you a place to collaborate with others and manage your work. For more information, see "[Creating a new repository](/github/creating-cloning-and-archiving-repositories/creating-a-repository-on-github/creating-a-new-repository)."
+
+You can set up repositories for different purposes based on your needs. The following are some common use cases:
+
+- **Product repositories**: Larger organizations that track their work and goals around specific products may have one or more repositories containing the code and other files. These repositories can also be used for documentation, reporting on product health or future plans for the product. 
+- **Project repositories**: You can create a repository for an individual project you are working on, or for a project you are collaborating on with others. For an organization that tracks work for short-lived initiatives or projects, such as a consulting firm, there is a need to report on the health of a project and move people between different projects based on skills and needs. Code for the project is often contained in a single repository.
+- **Team repositories**: For an organization that groups people into teams, and brings projects to them, such as a dev tools team, code may be scattered across many repositories for the different work they need to track. In this case it may be helpful to have a team-specific repository as one place to track all the work the team is involved in.
+- **Personal repositories**: You can create a personal repository to track all your work in one place, plan future tasks, or even add notes or information you want to save. You can also add collaborators if you want to share this information with others. 
+
+You can create multiple, separate repositories if you want different access permissions for the source code and for tracking issues and discussions. For more information, see "[Creating an issues-only repository](/github/creating-cloning-and-archiving-repositories/creating-a-repository-on-github/creating-an-issues-only-repository)."
+
+For the following examples in this guide, we will be using an example repository called Project Octocat.
+## Communicating repository information
+You can create a README.md file for your repository to introduce your team or project and communicate important information about it. A README is often the first item a visitor to your repository will see, so you can also provide information on how users or contributors can get started with the project and how to contact the team. For more information, see "[About READMEs](/github/creating-cloning-and-archiving-repositories/creating-a-repository-on-github/about-readmes)."
+
+You can also create a CONTRIBUTING.md file specifically to contain guidelines on how users or contributors can contribute and interact with the team or project, such as how to open a bug fix issue or request an improvement. For more information, see "[Setting guidelines for repository contributors](/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)."
+### README example
+We can create a README.md to introduce our new project, Project Octocat. 
+
+![Creating README example](/assets/images/help/issues/quickstart-creating-readme.png)
+## Creating issue templates
+
+You can use issues to track the different types of work that your cross-functional team or project covers, as well as gather information from those outside of your project. The following are a few common use cases for issues.
+
+- Release tracking: You can use an issue to track the progress for a release or the steps to complete the day of a launch.
+- Large initiatives: You can use an issue to track progress on a large initiative or project, which is then linked to the smaller issues.
+- Feature requests: Your team or users can create issues to request an improvement to your product or project.
+- Bugs: Your team or users can create issues to report a bug. 
+
+Depending on the type of repository and project you are working on, you may prioritize certain types of issues over others. Once you have identified the most common issue types for your team, you can create issue templates {% ifversion fpt %}and forms{% endif %} for your repository. Issue templates {% ifversion fpt %}and forms{% endif %} allow you to create a standardized list of templates that a contributor can choose from when they open an issue in your repository. For more information, see "[Configuring issue templates for your repository](/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository)."
+
+### Issue template example
+Below we are creating an issue template for reporting a bug in Project Octocat.
+
+![Creating issue template example](/assets/images/help/issues/quickstart-creating-issue-template.png)
+
+Now that we created the bug report issue template, you are able to select it when creating a new issue in Project Octocat.
+
+![Choosing issue template example](/assets/images/help/issues/quickstart-issue-creation-menu-with-template.png)
+
+## Opening issues and using task lists to track work
+You can organize and track your work by creating issues. For more information, see "[Creating an issue](/issues/tracking-your-work-with-issues/creating-issues/creating-an-issue)."
+### Issue example
+Here is an example of an issue created for a large initiative, front-end work, in Project Octocat.
+
+![Creating large initiative issue example](/assets/images/help/issues/quickstart-create-large-initiative-issue.png)
+### 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 %} 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 "[About task lists](/issues/tracking-your-work-with-issues/creating-issues/about-task-lists)."
+
+Below we have added a task list to our Project Octocat issue, breaking it down into smaller issues.
+
+![Adding task list to issue example](/assets/images/help/issues/quickstart-add-task-list-to-issue.png)
+
+## Making decisions as a team
+You can use issues and discussions to communicate and make decisions as a team on planned improvements or priorities for your project. Issues are useful when you create them for discussion of specific details, such as bug or performance reports, planning for the next quarter, or design for a new initiative. Discussions are useful for open-ended brainstorming or feedback, outside the codebase and across repositories. For more information, see "[Which discussion tool should I use?](/github/getting-started-with-github/quickstart/communicating-on-github#which-discussion-tool-should-i-use)."
+
+As a team, you can also communicate updates on day-to-day tasks within issues so that everyone knows the status of work. For example, you can create an issue for a large feature that multiple people are working on, and each team member can add updates with their status or open questions in that issue.
+### Issue example with project collaborators
+Here is an example of project collaborators giving a status update on their work on the Project Octocat issue.
+
+![Collaborating on issue example](/assets/images/help/issues/quickstart-collaborating-on-issue.png)
+## Using labels to highlight project goals and status
+You can create labels for a repository to categorize issues, pull requests, and discussions. {% data variables.product.prodname_dotcom %} also provides default labels for every new repository that you can edit or delete. Labels are useful for keeping track of project goals, bugs, types of work, and the status of an issue.
+
+For more information, see "[Creating a label](/issues/using-labels-and-milestones-to-track-work/managing-labels#creating-a-label)."
+
+Once you have created a label in a repository, you can apply it on any issue, pull request or discussion in the repository. You can then filter issues and pull requests by label to find all associated work. For example, find all the front end bugs in your project by filtering for issues with the `front-end` and `bug` labels. For more information, see "[Filtering issues and pull requests by labels](/github/administering-a-repository/finding-information-in-a-repository/filtering-issues-and-pull-requests-by-labels)."
+### Label example
+Below is an example of a `front-end` label that we created and added to the issue.
+
+![Adding a label to an issue example](/assets/images/help/issues/quickstart-add-label-to-issue.png)
+## Adding issues to a project board
+{% ifversion fpt %}You can use projects on {% data variables.product.prodname_dotcom %}, currently in limited public beta, to plan and track the work for your team. A project is a customizable spreadsheet that integrates with your issues and pull requests on {% data variables.product.prodname_dotcom %}, automatically staying up-to-date with the information on {% data variables.product.prodname_dotcom %}. You can customize the layout by filtering, sorting, and grouping your issues and PRs. To get started with projects, see "[Quickstart for projects (beta)](/issues/trying-out-the-new-projects-experience/quickstart)."
+### Project (beta) example
+Here is the table view of an example project, populated with the Project Octocat issues we have created.
+
+![Projects (beta) table view example](/assets/images/help/issues/quickstart-projects-table-view.png)
+
+We can also view the same project as a board.
+
+![Projects (beta) board view example](/assets/images/help/issues/quickstart-projects-board-view.png)
+
+{% endif %}
+
+You can {% ifversion fpt %} also use the existing{% else %} use{% endif %} project boards on {% data variables.product.prodname_dotcom %} to plan and track your or your team's work. Project boards are made up of issues, pull requests, and notes that are categorized as cards in columns of your choosing. You can create project boards for feature work, high-level roadmaps, or even release checklists. For more information, see "[About project boards](/issues/organizing-your-work-with-project-boards/managing-project-boards/about-project-boards)."
+### Project board example
+Below is a project board for our example Project Octocat with the issue we created, and the smaller issues we broke it down into, added to it.
+
+![Project board example](/assets/images/help/issues/quickstart-project-board.png)
+## Next steps
+
+You have now learned about the tools {% data variables.product.prodname_dotcom %} offers for planning and tracking your work, and made a start in setting up your cross-functional team or project repository! Here are some helpful resources for further customizing your repository and organizing your work.
+
+- "[About repositories](/github/creating-cloning-and-archiving-repositories/creating-a-repository-on-github/about-repositories)" for learning more about creating repositories
+- "[Tracking your work with issues](/issues/tracking-your-work-with-issues)" for learning more about different ways to create and manage issues
+- "[About issues and pull request templates](/communities/using-templates-to-encourage-useful-issues-and-pull-requests/about-issue-and-pull-request-templates)" for learning more about issue templates
+- "[Managing labels](/issues/using-labels-and-milestones-to-track-work/managing-labels)" for learning how to create, edit and delete labels
+- "[About task lists](/issues/tracking-your-work-with-issues/creating-issues/about-task-lists)" for learning more about task lists
+{% ifversion fpt %} - "[About projects (beta)](/issues/trying-out-the-new-projects-experience/about-projects)" for learning more about the new projects experience, currently in limited public beta 
+- "[Customizing your project (beta) views](/issues/trying-out-the-new-projects-experience/customizing-your-project-views)" for learning how to customize views for projects, currently in limited public beta{% endif %}
+- "[About project boards](/issues/organizing-your-work-with-project-boards/managing-project-boards/about-project-boards)" for learning how to manage project boards

content/packages/managing-github-packages-using-github-actions-workflows/publishing-and-installing-a-package-with-github-actions.md

@@ -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>

data/reusables/actions/actions-not-certified-by-github-note.md

@@ -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 %}

data/reusables/code-scanning/custom-configuration-file.md

@@ -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_.

data/reusables/package_registry/publish-docker-image.md

@@ -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 %}
+