Repo sync

.github/workflows/close-on-invalid-label.yaml

@@ -18,8 +18,8 @@ permissions:
   pull-requests: write
 
 jobs:
-  close-on-adding-invalid-label:
-    if: github.repository == 'github/docs' && github.event.label.name == 'invalid'
+  close-if-invalid:
+    if: github.repository == 'github/docs' && (github.event.label.name == 'invalid' || github.event.pull_request.title == 'Revert "Repo sync"')
     runs-on: ubuntu-latest
 
     steps:

.github/workflows/codespace-review-check.yml

@@ -32,17 +32,19 @@ jobs:
           LOGIN: docs-bot
           REPO: github/docs-internal
         run: |
-          ago=$(date -d '225 minutes ago' -Iseconds)
+          # If its approaching 4 hours, update the comment
+          # But don't keep trying to update the comment after 5 hours cause that wastes API calls
+          from=$(date -d '285 minutes ago' -Iseconds)  # 5 * 60 - 15 = 285
+          until=$(date -d '225 minutes ago' -Iseconds)  # 4 * 60 - 15 = 225
           echo "- Ago: $ago"
           # on mac: date -v-225M -Iseconds
-          #   -v-225M means 225 minutes ago, 4 * 60 - 15 = 225
           # -Iseconds means ISO 8601 format, to seconds
           branches=$(
             gh codespace list \
               --repo "$REPO" \
               --limit 1000 \
               --json name,owner,lastUsedAt,gitStatus \
-              --jq ".[] | select(.owner == \"$LOGIN\" and .lastUsedAt < \"$ago\") | .gitStatus.ref" \
+              --jq ".[] | select(.owner == \"$LOGIN\" and .lastUsedAt < \"$until\" and .lastUsedAt > \"$from\") | .gitStatus.ref" \
           )
           echo "- Branches:"
           echo "$(echo "$branches" | sed 's/^/    /')"
@@ -111,14 +113,14 @@ jobs:
 
             ### Review this PR in a codespace 📦
 
-            Your codespace is no longer active.
+            The codespace is no longer active.
             You’ve reached the 4 hour limit.
-            In order to reactivate your codespace, please update your pull request by adding the https://github.com/${{ env.REPO }}/labels/extend-codespace label.
-            If the label is already applied, you can remove and reapply the label to reactivate your codespace.
+            In order to reactivate the codespace, please update the pull request by adding the https://github.com/${{ env.REPO }}/labels/extend-codespace label.
+            If the label is already applied, you can remove and reapply the label to reactivate the codespace.
 
             🤖 This comment is [automatically generated][workflow].
 
-            [workflow]: ${{ github.server_url }}/${{ github.repository }}/blob/${{ github.sha }}/.github/workflows/codespace-review-check.yml
+            [workflow]: ${{ github.server_url }}/${{ github.repository }}/blob/${{ github.workflow_sha }}/.github/workflows/codespace-review-check.yml
 
       - uses: ./.github/actions/slack-alert
         if: ${{ failure() && github.event_name != 'workflow_dispatch' }}

.github/workflows/codespace-review-down.yml

@@ -77,8 +77,8 @@ jobs:
 
             ### Review this PR in a codespace 📦
 
-            Your pull request is now merged or closed, so I've removed all automatically created codespaces.
+            The pull request is now merged or closed, so I've removed all automatically created codespaces.
 
             🤖 This comment is [automatically generated][workflow].
 
-            [workflow]: ${{ github.server_url }}/${{ github.repository }}/blob/${{ github.sha }}/.github/workflows/codespace-review-down.yml
+            [workflow]: ${{ github.server_url }}/${{ github.repository }}/blob/${{ github.workflow_sha }}/.github/workflows/codespace-review-down.yml

.github/workflows/codespace-review-up.yml

@@ -107,7 +107,7 @@ jobs:
               gh pr comment \
                 "$branch" \
                 --repo "$REPO" \
-                --body "Thank you for your pull request. I deleted the oldest codespaces to make room for a new one. You can make a new codespace by updating your pull request or closing and reopening your pull request."
+                --body "Thank you for this pull request. I deleted the oldest codespaces to make room for a new one. You can make a new codespace by updating the pull request or closing and reopening the pull request."
               echo "Commented on branch $branch"
             done
             echo "Deleted the oldest $tocut codespaces"
@@ -205,18 +205,18 @@ jobs:
 
             ### Review this PR in a codespace 📦
 
-            Your codespace will be ready in two to three minutes and you can review changes at:
+            The codespace will be ready in two to three minutes and you can review changes at:
             ${{ env.APP_URL }}
-            Your codespace will be automatically deleted once your pull request is closed or merged.
+            The codespace will be automatically deleted once the pull request is closed or merged.
 
-            #### Your codespace will idle after 4 hours of inactivity
+            #### The codespace will idle after 4 hours of inactivity
 
-            After 4 hours, you can reactivate your codespace by applying the https://github.com/${{ env.REPO }}/labels/extend-codespace label to the pull request.
-            If the label is already applied, you can remove and reapply the label to reactivate your codespace.
+            After 4 hours, you can reactivate the codespace by applying the https://github.com/${{ env.REPO }}/labels/extend-codespace label to the pull request.
+            If the label is already applied, you can remove and reapply the label to reactivate the codespace.
 
             <details><summary>Table of review links</summary>
 
-            ${{ steps.changes.outputs.changesTable && 'The table shows the files in the `content` directory that were changed in this pull request. This helps you review your changes on the review server. Changes to the `data` directory are not included in this table.' || '' }}
+            ${{ steps.changes.outputs.changesTable && 'The table shows the files in the `content` directory that were changed in this pull request. Changes to the `data` directory are not included in this table.' || '' }}
 
             ${{ steps.changes.outputs.changesTable || '_This pull request contains code changes, so we will not generate a table of review links._' }}
 
@@ -226,4 +226,4 @@ jobs:
 
             🤖 This comment is [automatically generated][workflow].
 
-            [workflow]: ${{ github.server_url }}/${{ github.repository }}/blob/${{ github.sha }}/.github/workflows/codespace-review-up.yml
+            [workflow]: ${{ github.server_url }}/${{ github.repository }}/blob/${{ github.workflow_sha }}/.github/workflows/codespace-review-up.yml

.github/workflows/review-comment.yml

@@ -100,6 +100,6 @@ jobs:
 
             🤖 This comment is [automatically generated][workflow].
 
-            [workflow]: ${{ github.server_url }}/${{ github.repository }}/blob/${{ github.sha }}/.github/workflows/review-comment.yml
+            [workflow]: ${{ github.server_url }}/${{ github.repository }}/blob/${{ github.workflow_sha }}/.github/workflows/review-comment.yml
             [codespace]: ${{ github.repository == 'github/docs-internal' && 'https://github.com/github/docs-team/blob/main/contributing-to-docs/use-a-codespace-to-review.md' || 'https://docs.github.com/en/contributing/setting-up-your-environment-to-work-on-github-docs/working-on-github-docs-in-a-codespace' }}
             [local]: https://docs.github.com/en/contributing/setting-up-your-environment-to-work-on-github-docs/creating-a-local-environment#setting-up-your-local-environment

content/actions/managing-workflow-runs-and-deployments/managing-deployments/managing-environments-for-deployment.md

@@ -126,7 +126,7 @@ Once custom deployment protection rules have been created and installed on a rep
 
 ## Environment secrets
 
-Secrets stored in an environment are only available to workflow jobs that reference the environment. If the environment requires approval, a job cannot access environment secrets until one of the required reviewers approves it. For more information about secrets, see [AUTOTITLE](/actions/security-guides/using-secrets-in-github-actions).
+Secrets stored in an environment are only available to workflow jobs that reference the environment. If the environment requires approval, a job cannot access environment secrets until one of the required reviewers approves it. For more information about secrets, see [AUTOTITLE](/actions/security-for-github-actions/security-guides/about-secrets).
 
 {% ifversion fpt %}
 > [!NOTE]

content/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-gitlab-cicd-to-github-actions.md

@@ -264,7 +264,7 @@ For more information, see [AUTOTITLE](/actions/using-workflows/events-that-trigg
 
 GitLab CI/CD and {% data variables.product.prodname_actions %} support setting variables in the pipeline or workflow configuration file, and creating secrets using the GitLab or {% data variables.product.github %} UI.
 
-For more information, see [AUTOTITLE](/actions/learn-github-actions/variables) and [AUTOTITLE](/actions/security-guides/using-secrets-in-github-actions).
+For more information, see [AUTOTITLE](/actions/learn-github-actions/variables) and [AUTOTITLE](/actions/security-for-github-actions/security-guides/about-secrets).
 
 ## Caching
 

content/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-travis-ci-to-github-actions.md

@@ -163,7 +163,7 @@ When migrating from Travis CI, consider the following key features in {% data va
 
 ### Storing secrets
 
-{% data variables.product.prodname_actions %} allows you to store secrets and reference them in your jobs. {% data variables.product.prodname_actions %} organizations can limit which repositories can access organization secrets. Deployment protection rules can require manual approval for a workflow to access environment secrets. For more information, see [AUTOTITLE](/actions/security-guides/using-secrets-in-github-actions).
+{% data variables.product.prodname_actions %} allows you to store secrets and reference them in your jobs. {% data variables.product.prodname_actions %} organizations can limit which repositories can access organization secrets. Deployment protection rules can require manual approval for a workflow to access environment secrets. For more information, see [AUTOTITLE](/actions/security-for-github-actions/security-guides/about-secrets).
 
 ### Sharing files between jobs and workflows
 

content/actions/security-for-github-actions/security-guides/about-secrets.md

@@ -0,0 +1,52 @@
+---
+title: About secrets
+intro: 'Learn about secrets as they''re used in GitHub Actions.'
+versions:
+  fpt: '*'
+  ghes: '*'
+  ghec: '*'
+---
+
+{% data reusables.actions.enterprise-github-hosted-runners %}
+
+## About secrets
+
+Secrets allow you to store sensitive information in your organization, repository, or repository environments. Secrets are variables that you create to use in {% data variables.product.prodname_actions %} workflows in an organization, repository, or repository environment.
+
+{% data variables.product.prodname_actions %} can only read a secret if you explicitly include the secret in a workflow.
+
+## Naming your secrets
+
+>[!TIP]
+> To help ensure that {% data variables.product.prodname_dotcom %} redacts your secrets in logs correctly, avoid using structured data as the values of secrets.
+
+The following rules apply to secret names:
+
+{% data reusables.actions.actions-secrets-and-variables-naming %}
+
+{% data reusables.codespaces.secret-precedence %} Similarly, if an organization, repository, and environment all have a secret with the same name, the environment-level secret takes precedence.
+
+## Using your secrets in workflows
+
+{% data reusables.actions.secrets-redaction-warning %}
+
+{% data reusables.actions.secrets-org-level-overview %}
+
+For environment secrets, you can enable required reviewers to control access to the secrets. A workflow job cannot access environment secrets until approval is granted by required approvers.
+
+To make a secret available to an action, you must set the secret as an input or environment variable in your workflow file. Review the action's README file to learn about which inputs and environment variables the action expects. See [AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsenv).
+
+Organization and repository secrets are read when a workflow run is queued, and environment secrets are read when a job referencing the environment starts.
+
+## Limiting credential permissions
+
+When generating credentials, we recommend that you grant the minimum permissions possible. For example, instead of using personal credentials, use [deploy keys](/authentication/connecting-to-github-with-ssh/managing-deploy-keys#deploy-keys) or a service account. Consider granting read-only permissions if that's all that is needed, and limit access as much as possible.
+
+When generating a {% data variables.product.pat_v1 %}, select the fewest scopes necessary. When generating a {% data variables.product.pat_v2 %}, select the minimum permissions and repository access required.
+
+Instead of using a {% data variables.product.pat_generic %}, consider using a {% data variables.product.prodname_github_app %}, which uses fine-grained permissions and short lived tokens, similar to a {% data variables.product.pat_v2 %}. Unlike a {% data variables.product.pat_generic %}, a {% data variables.product.prodname_github_app %} is not tied to a user, so the workflow will continue to work even if the user who installed the app leaves your organization. For more information, see [AUTOTITLE](/apps/creating-github-apps/guides/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow).
+
+## Further reading
+
+* [AUTOTITLE](/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions)
+* [AUTOTITLE](/rest/actions/secrets)

content/actions/security-for-github-actions/security-guides/index.md

@@ -8,6 +8,7 @@ versions:
   ghec: '*'
 children:
   - /security-hardening-for-github-actions
+  - /about-secrets
   - /using-secrets-in-github-actions
   - /automatic-token-authentication
   - /using-githubs-security-features-to-secure-your-use-of-github-actions

content/actions/security-for-github-actions/security-guides/using-githubs-security-features-to-secure-your-use-of-github-actions.md

@@ -80,7 +80,7 @@ For information on how to configure {% data variables.product.prodname_dependabo
 
 ## Protecting actions you've created
 
-{% data variables.product.prodname_dotcom %} enables collaboration between people who publish and maintain actions and vulnerability reporters in order to promote code security. {% data reusables.security-advisory.security-advisory-overview %}
+{% data variables.product.prodname_dotcom %} enables collaboration between people who publish and maintain actions and vulnerability reporters in order to promote secure coding. {% data reusables.security-advisory.security-advisory-overview %}
 
 If you are someone who maintains an action that is used in other projects, you can use the following {% data variables.product.prodname_dotcom %} features to enhance the security of the actions you've published.
 

content/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions.md

@@ -19,51 +19,7 @@ versions:
 
 {% data reusables.actions.enterprise-github-hosted-runners %}
 
-## About secrets
-
-Secrets are variables that you create in an organization, repository, or repository environment. The secrets that you create are available to use in {% data variables.product.prodname_actions %} workflows. {% data variables.product.prodname_actions %} can only read a secret if you explicitly include the secret in a workflow.
-
-{% data reusables.actions.secrets-org-level-overview %}
-
-For secrets stored at the environment level, you can enable required reviewers to control access to the secrets. A workflow job cannot access environment secrets until approval is granted by required approvers.
-
-> [!NOTE]
-> {% data reusables.actions.about-oidc-short-overview %}
-
-### Naming your secrets
-
-The following rules apply to secret names:
-
-{% data reusables.actions.actions-secrets-and-variables-naming %}
-
-  For example, a secret created at the environment level must have a unique name in that environment, a secret created at the repository level must have a unique name in that repository, and a secret created at the organization level must have a unique name at that level.
-
-  {% data reusables.codespaces.secret-precedence %} Similarly, if an organization, repository, and environment all have a secret with the same name, the environment-level secret takes precedence.
-
-To help ensure that {% data variables.product.prodname_dotcom %} redacts your secrets in logs correctly, avoid using structured data as the values of secrets. For example, avoid creating secrets that contain JSON or encoded Git blobs. Using structured data as secrets could cause non-secrets to be detected as such, making passing data between workflows harder to implement. In such cases, consider manipulating the structured data, for example encoding them to a string, before storing them as secrets, and decoding them before they are used.
-
-### Accessing your secrets
-
-To make a secret available to an action, you must set the secret as an input or environment variable in the workflow file. Review the action's README file to learn about which inputs and environment variables the action expects. For more information, see [AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsenv).
-
-You can use and read secrets in a workflow file if you have access to edit the file. For more information, see [AUTOTITLE](/get-started/learning-about-github/access-permissions-on-github).
-
-{% data reusables.actions.secrets-redaction-warning %}
-
-Organization and repository secrets are read when a workflow run is queued, and environment secrets are read when a job referencing the environment starts.
-
-You can also manage secrets using the REST API. For more information, see [AUTOTITLE](/rest/actions/secrets).
-
-### Limiting credential permissions
-
-When generating credentials, we recommend that you grant the minimum permissions possible. For example, instead of using personal credentials, use [deploy keys](/authentication/connecting-to-github-with-ssh/managing-deploy-keys#deploy-keys) or a service account. Consider granting read-only permissions if that's all that is needed, and limit access as much as possible.
-
-When generating a {% data variables.product.pat_v1 %}, select the fewest scopes necessary. When generating a {% data variables.product.pat_v2 %}, select the minimum permissions and repository access required.
-
-Instead of using a {% data variables.product.pat_generic %}, consider using a {% data variables.product.prodname_github_app %}, which uses fine-grained permissions and short lived tokens, similar to a {% data variables.product.pat_v2 %}. Unlike a {% data variables.product.pat_generic %}, a {% data variables.product.prodname_github_app %} is not tied to a user, so the workflow will continue to work even if the user who installed the app leaves your organization. For more information, see [AUTOTITLE](/apps/creating-github-apps/guides/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow).
-
-> [!NOTE]
-> Users with collaborator access to a repository can use the REST API to manage secrets for that repository, and users with admin access to an organization can use the REST API to manage secrets for that organization. For more information, see [AUTOTITLE](/rest/actions/secrets).
+For general information about secrets, see [AUTOTITLE](/actions/security-for-github-actions/security-guides/about-secrets).
 
 ## Creating secrets for a repository
 
@@ -212,6 +168,7 @@ You can check which access policies are being applied to a secret in your organi
 > [!NOTE]
 > * {% data reusables.actions.forked-secrets %}
 > * Secrets are not automatically passed to reusable workflows. For more information, see [AUTOTITLE](/actions/using-workflows/reusing-workflows#passing-inputs-and-secrets-to-a-reusable-workflow).
+> {% data reusables.actions.about-oidc-short-overview %}
 
 To provide an action with a secret as an input or environment variable, you can use the `secrets` context to access secrets you've created in your repository. For more information, see [AUTOTITLE](/actions/learn-github-actions/contexts) and [AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions).