Repo sync

.github/workflows/check-for-spammy-issues.yml

@@ -30,6 +30,7 @@ jobs:
             const titleWordCountMin = 3
             const urlRegex = /https?:\/\/\S+/i
             const titleHasUrl = urlRegex.test(issue.title)
+            const titleHasDollarSign = issue.title.includes('$')
 
             try {
               await github.rest.teams.getMembershipForUserInOrg({
@@ -45,7 +46,7 @@ jobs:
               // An error will be thrown if the user is not a GitHub employee
               // If a user is not a GitHub employee, we should check to see if title has at least the minimum required number of words in it and if it does, we can exit the workflow
 
-              if (titleWordCount >= titleWordCountMin && !titleHasUrl) {
+              if (titleWordCount >= titleWordCountMin && !titleHasUrl && !titleHasDollarSign) {
                 return
               }
             }

.github/workflows/check-for-spammy-prs.yml

@@ -37,13 +37,19 @@ jobs:
             const onlyDeletes = files.length > 0 && files.every(f => f.status === 'removed')
             const isEmptyCommit = !files.length 
             const touchesTooMany = files.length > 10
-            const totalChanges = files.reduce((sum, f) => sum + f.additions + f.deletions, 0)
-            const isOneLineAddition = files.every(f => f.status === 'added') && totalChanges <= 1
-            const isBlankLineEdit = totalChanges <= 1 && files.every(f => f.status === 'modified')
+            const isBlankLineEdit = files.length > 0 && files.every(file => {
+              const changedLines = (file.patch || '')
+                .split('\n')
+                .filter(line => /^[+-]/.test(line))
+                )
+
+              return changedLines.length > 0 &&
+                changedLines.every(line => line.slice(1).trim() === '')
+            })
             const onlyRenames = files.length > 0 && files.every(f => f.status === 'renamed')
 
             // Close the PR and add the invalid label
-            if (onlyDeletes || isEmptyCommit || touchesTooMany || isOneLineAddition || isBlankLineEdit || onlyRenames) {
+            if (onlyDeletes || isEmptyCommit || touchesTooMany || isBlankLineEdit || onlyRenames) {
               await github.rest.issues.update({
                 owner: owner,
                 repo: repo,

.github/workflows/send-to-triage-board.yml

@@ -0,0 +1,45 @@
+name: Add new issues and PRs to central triage board
+
+# **What it does**: Adds newly opened or reopened issues and pull requests in github/docs to the right place for triage, and stamps the item with today's date.
+# **Why we have it**: To ensure incoming work in the public docs repo is triaged properly.
+# **Who does it impact**: Writers, FRs.
+
+on:
+  issues:
+    types: [opened, reopened]
+  pull_request_target:
+    types: [opened, reopened, ready_for_review]
+
+permissions:
+  contents: read
+
+jobs:
+  add-to-central-triage:
+    runs-on: ubuntu-latest
+    if: github.repository == 'github/docs'
+    steps:
+      - name: Triage to central triage board
+        env:
+          GITHUB_TOKEN: ${{ secrets.DOCS_BOT_PAT_BASE }}
+          ITEM_URL: ${{ github.event.issue.html_url || github.event.pull_request.html_url }}
+          # Add to the Central Triage Group project board and set date to now
+          PROJECT_NUMBER: '19598'
+          PROJECT_ID: 'PVT_kwDNJr_OAJ4AfQ'
+          DATE_FIELD_ID: 'PVTF_lADNJr_OAJ4Afc4IAbbv'
+        run: |
+          echo "Adding $ITEM_URL to project $PROJECT_NUMBER..."
+          ITEM_ID=$(gh project item-add "$PROJECT_NUMBER" --owner github --url "$ITEM_URL" --format json --jq '.id' || true)
+
+          sleep 10
+
+          if [ -n "$ITEM_ID" ] && [ "$ITEM_ID" != "null" ]; then
+            echo "Editing date on item $ITEM_ID..."
+            DATE=$(date '+%Y-%m-%d')
+            if gh project item-edit --project-id "$PROJECT_ID" --id "$ITEM_ID" --field-id "$DATE_FIELD_ID" --date "$DATE"; then
+              echo "done editing"
+            else
+              echo "::warning::gh project item-edit failed for $ITEM_URL (item $ITEM_ID); the item is on the board but the date field was not set"
+            fi
+          else
+            echo "::warning::gh project item-add did not return an item id for $ITEM_URL; skipping item-edit"
+          fi

content/actions/concepts/security/openid-connect.md

@@ -99,6 +99,12 @@ To use OIDC in your workflows, you must establish a trust relationship between {
 
 Before granting an access token, your cloud provider checks that the [`subject`](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) and any other claims used to set conditions in its trust settings match those in the request's JSON Web Token (JWT). If the trust configuration matches, your cloud provider issues a temporary access token to the workflow.
 
+{% ifversion dependabot-oidc-support %}
+
+OIDC tokens requested for {% data variables.product.prodname_dependabot %} update jobs have an `event_name` claim of `dynamic`. If your trust policy is intended to authorize only {% data variables.product.prodname_actions %} workflows and your cloud provider supports conditions on `event_name`, allow only the event names expected by your workflows.
+
+{% endif %}
+
 For steps and syntax for configuring OIDC trust and setting conditions for cloud providers, see [AUTOTITLE](/actions/reference/security/oidc#oidc-claims-used-to-define-trust-conditions-on-cloud-roles).
 
 ## Configuring OIDC on {% data variables.enterprise.data_residency_site %}

content/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-jfrog.md

@@ -34,7 +34,7 @@ For an example {% data variables.product.prodname_actions %} workflow using the
 
 * To be secure, you need to set a Claims JSON in JFrog when configuring identity mappings. For more information, see [AUTOTITLE](https://jfrog.com/help/r/jfrog-platform-administration-documentation/configure-identity-mappings) and [AUTOTITLE](/actions/reference/security/oidc#customizing-the-token-claims).
 
-    For example, you can set `iss` to `https://token.actions.githubusercontent.com`, and the `repository` to something like "octo-org/octo-repo"`. This will ensure only Actions workflows from the specified repository will have access to your JFrog platform. The following is an example Claims JSON when configuring identity mappings.
+  For example, you can set `iss` to `https://token.actions.githubusercontent.com`, and the `repository` to something like `octo-org/octo-repo`.{% ifversion dependabot-oidc-support %} JFrog identity mappings match each claim against an exact value, so to ensure only {% data variables.product.prodname_actions %} workflows from the specified repository have access to your JFrog platform, also set `event_name` to the event that triggers your workflow, such as `push`. This prevents OIDC tokens requested for {% data variables.product.prodname_dependabot %} update jobs, which have an `event_name` of `dynamic`, from matching the identity mapping. If your workflows are triggered by more than one event, create a separate identity mapping for each event name.{% endif %} The following is an example Claims JSON when configuring identity mappings.
 
     {% data reusables.actions.jfrog-json-configuring-identity-mappings %}
 

content/actions/reference/security/oidc.md

@@ -60,7 +60,7 @@ The OIDC token includes the following claims.
 | `enterprise_id`| The ID of the enterprise that contains the repository from where the workflow is running.                  |
 | {% endif %} |
 | `environment`| The name of the environment used by the job. If the `environment` claim is included (also via `include_claim_keys`), an environment is required and must be provided.                   |
-| `event_name`| The name of the event that triggered the workflow run.                    |
+| `event_name`| The name of the event that triggered the workflow run.{% ifversion dependabot-oidc-support %} OIDC tokens requested for {% data variables.product.prodname_dependabot %} update jobs use `dynamic` as the value.{% endif %}                    |
 | `head_ref`| The source branch of the pull request in a workflow run.                   |
 | `job_workflow_ref`| For jobs using a reusable workflow, the ref path to the reusable workflow. For more information, see [AUTOTITLE](/actions/how-tos/secure-your-work/security-harden-deployments/oidc-with-reusable-workflows).                  |
 | `job_workflow_sha`| For jobs using a reusable workflow, the commit SHA for the reusable workflow file.                   |
@@ -107,6 +107,12 @@ If you need more granular trust conditions, you can customize the {% ifversion g
 
 There are also many additional claims supported in the OIDC token that can be used for setting these conditions. In addition, your cloud provider could allow you to assign a role to the access tokens, letting you specify even more granular permissions.
 
+{% ifversion dependabot-oidc-support %}
+
+OIDC tokens requested for {% data variables.product.prodname_dependabot %} update jobs have an `event_name` claim of `dynamic`. If your trust policy is intended to authorize only {% data variables.product.prodname_actions %} workflows and your cloud provider supports conditions on `event_name`, allow only the event names expected by your workflows.
+
+{% endif %}
+
 > [!NOTE]
 > To control how your cloud provider issues access tokens, you **must** define at least one condition, so that untrusted repositories can’t request access tokens for your cloud resources.
 

content/copilot/concepts/agents/copilot-cli/about-copilot-cli.md

@@ -80,7 +80,7 @@ You can start a {% data variables.copilot.copilot_cli_short %} session inside an
 To start a cloud-backed session, run:
 
 ```bash copy
-copilot ‑‑cloud
+copilot --cloud
 ```
 
 ## Use cases for {% data variables.copilot.copilot_cli %}

content/copilot/how-tos/copilot-cli/automate-copilot-cli/schedule-prompts.md

@@ -73,7 +73,7 @@ The prompt fires once, after the delay has elapsed, and is then removed from the
 You can use `/every` and `/after` to schedule a skill. To do this, you can reference the skill explicitly by using its slash command, or you can use natural language to tell {% data variables.product.prodname_copilot_short %} to run the skill.
 
 > [!NOTE]
-> Only user-invocable skills can be scheduled this way. You cannot include built-in slash commands (such as `/clear`) in a scheduled prompt.
+> Only user-invocable skills and a subset of built-in slash commands can be scheduled. Commands that start a self-contained piece of work—such as `/plan`, `/review`, `/research`, or `/security-review`—are schedulable. Commands that change your session or configuration (for example, `/model`, `/clear`, `/compact`, `/permissions`, or `/sandbox`), that only display information (such as `/usage` or `/context`), or that manage scheduling itself (`/every` and `/after`) can't be scheduled, and {% data variables.product.prodname_copilot_short %} rejects them when you try.
 
 ### Examples
 
@@ -94,9 +94,11 @@ You can use `/every` and `/after` to schedule a skill. To do this, you can refer
 | `h`    | hours   | `2h`    |
 | `d`    | days    | `1d`    |
 
-A bare number with no suffix is interpreted as minutes—for example, `/every 30 remind me to check for Slack messages` schedules the prompt every 30 minutes.
+When you specify a numeric duration, always include the suffix. A bare number—for example, `/every 30 remind me to check for Slack messages`—is not recognized as an interval.
 
-The minimum interval is **10 seconds** and the maximum is **1 day** (24 hours).
+For a fixed interval, the minimum is **10 seconds** and the maximum is **1 day** (24 hours).
+
+You can also describe the timing in plain language instead of using a duration—for example, `/after at 3pm push the release`, or `/every day at 9am post the standup`. {% data variables.product.prodname_copilot_short %} uses a model to interpret the phrase, then creates the schedule from it.
 
 ## Identifying scheduled prompts in the session
 
@@ -116,9 +118,9 @@ Press <kbd>Esc</kbd> to exit the schedule list.
 
 Scheduled prompts are scoped to the session they were created in, and they are only triggered while that session is running.
 
-When you reopen the session (using the `--continue` or `--resume` command line options) the schedules are restarted, with interval before a schedule is triggered measured from the moment you reopen the session.
+When you reopen the session (using the `--continue` or `--resume` command line options) the schedules are restored. For a recurring schedule created with a fixed interval, the wait before the next run is measured from the moment you reopen the session.
 
-If an `/after` schedule had not been triggered before you closed the session, it remains in the schedule list and will be triggered after the specified delay in the reopened session.
+An `/after` schedule that had not been triggered before you closed the session keeps its original target time, rather than restarting the delay. If that time passed while the session was closed, the prompt is submitted as soon as you reopen the session.
 
 ## Running a prompt from an external scheduler