Change codeNavigation to 'supported' for C and C++

Author: ashis-baral

.github/workflows/codeql.yml

@@ -30,6 +30,14 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
+      - name: Generate GitHub App token
+        id: app-token
+        uses: actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0
+        with:
+          app-id: ${{ secrets.DOCS_BOT_APP_ID }}
+          private-key: ${{ secrets.DOCS_BOT_APP_PRIVATE_KEY }}
+          owner: github
+          repositories: docs-engineering
 
       - uses: github/codeql-action/init@e296a935590eb16afc0c0108289f68c87e2a89a5 # v4.30.7
         with:
@@ -42,16 +50,6 @@ jobs:
         with:
           slack_token: ${{ secrets.SLACK_DOCS_BOT_TOKEN }}
 
-      - name: Generate GitHub App token
-        if: ${{ failure() && github.event_name != 'pull_request' }}
-        id: app-token
-        uses: actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0
-        with:
-          app-id: ${{ secrets.DOCS_BOT_APP_ID }}
-          private-key: ${{ secrets.DOCS_BOT_APP_PRIVATE_KEY }}
-          owner: github
-          repositories: docs-engineering
-
       - uses: ./.github/actions/create-workflow-failure-issue
         if: ${{ failure() && github.event_name != 'pull_request' }}
         with:

.github/workflows/purge-fastly.yml

@@ -27,7 +27,6 @@ on:
 
 permissions:
   contents: read
-  deployments: read
 
 # Serialize full-cache purges so two can't overlap and leave the cache in an
 # unknown state. Every other run (per-deploy, per-language) gets a unique group
@@ -105,20 +104,6 @@ jobs:
           fi
           npm run purge-fastly -- "${args[@]}"
 
-      - name: Hard-purge changed English content URLs
-        # Prod deploys only. The soft purge above just marks `language:en` stale,
-        # so stale-while-revalidate can keep serving the pre-deploy copy of a
-        # just-changed page for a while. This evicts the specific English URLs
-        # whose content/ files changed in this deploy, so the next request fetches
-        # fresh. By the time the deploy succeeds the old pods are already gone, so
-        # the refill is deterministically the new content. data/ changes stay
-        # covered by the soft purge above (too many URLs to enumerate cheaply).
-        if: ${{ github.event_name == 'deployment_status' }}
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-          HEAD_SHA: ${{ github.event.deployment.sha }}
-        run: npm run purge-fastly-changed-content
-
       - uses: ./.github/actions/slack-alert
         if: ${{ failure() && github.event_name != 'workflow_dispatch' }}
         with:

content/actions/get-started/understand-github-actions.md

@@ -71,10 +71,6 @@ For a complete list of events that can be used to trigger workflows, see [Events
 
 A **job** is a set of **steps** in a workflow that is executed on the same **runner**. Each step is either a shell script that will be executed, or an **action** that will be run. Steps are executed in order and are dependent on each other. Since each step is executed on the same runner, you can share data from one step to another. For example, you can have a step that builds your application followed by a step that tests the application that was built.
 
-{% ifversion actions-nga %}
-Steps run in order by default, but you can also run selected steps concurrently when your workflow benefits from parallel execution, such as starting a long-running service while later steps continue. For more information, see [AUTOTITLE](/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsbackground).
-{% endif %}
-
 You can configure a job's dependencies with other jobs; by default, jobs have no dependencies and run in parallel. When a job takes a dependency on another job, it waits for the dependent job to complete before running.
 
 You can also use a **matrix** to run the same job multiple times, each with a different combination of variables—like operating systems or language versions.

content/actions/reference/workflows-and-actions/workflow-syntax.md

@@ -903,143 +903,6 @@ The maximum number of minutes to run the step before killing the process. Maximu
 
 Fractional values are not supported. `timeout-minutes` must be a positive integer.
 
-{% ifversion actions-nga %}
-
-## `jobs.<job_id>.steps[*].background`
-
-Runs a step asynchronously so the job continues to the next step without waiting for it to finish. Use `background: true` for long-running processes, such as databases, servers, or monitoring tasks, that need to run alongside other steps. You synchronize with background steps later using [`wait`](#jobsjob_idstepswait) or [`wait-all`](#jobsjob_idstepswait-all) or stop them with [`cancel`](#jobsjob_idstepscancel).
-
-You can use `background` on steps that use `run` or `uses`. To reference a background step from [`wait`](#jobsjob_idstepswait) or [`cancel`](#jobsjob_idstepscancel), give it an [`id`](#jobsjob_idstepsid). A maximum of 10 background steps can run concurrently in a single job; additional background steps are queued until a slot is free.
-
-Outputs and environment changes from a background step are only available after you run a `wait` or `wait-all` step that includes it. If a background step fails, the job fails at the next `wait` or `wait-all` that includes it (unless [`continue-on-error`](#jobsjob_idstepscontinue-on-error) is set on that step). An implicit `wait-all` runs before any post-job cleanup.
-
-Use `background` when you need fine-grained control: starting a long-running process (like a server or database) that stays up while later steps run, referencing a specific step with [`wait`](#jobsjob_idstepswait) or [`cancel`](#jobsjob_idstepscancel), or interleaving background work with other steps. If you instead have a self-contained group of steps that should all finish before the job continues, [`parallel`](#jobsjob_idstepsparallel) is a more convenient shorthand.
-
-### Example: Running a step in the background
-
-```yaml
-steps:
-  - name: Start server
-    id: server
-    run: npm start
-    background: true
-
-  - name: Run tests against the server
-    run: npm test
-
-  - name: Wait for the server step to finish
-    wait: server
-```
-
-## `jobs.<job_id>.steps[*].wait`
-
-Pauses the job until one or more background steps complete. A `wait` step performs no work itself, it only blocks until the referenced background steps finish. Provide a single step `id` as a string, or multiple step `id`s as an array.
-
-After a `wait` step completes, the outputs of the referenced background steps become available to subsequent steps. If a referenced background step failed, the `wait` step fails too.
-
-### Example: Waiting for specific background steps
-
-```yaml
-steps:
-  - name: Build frontend
-    id: build-frontend
-    run: npm run build:frontend
-    background: true
-
-  - name: Build backend
-    id: build-backend
-    run: npm run build:backend
-    background: true
-
-  - name: Run linter while builds run
-    run: npm run lint
-
-  - name: Wait for both builds to finish
-    wait: [build-frontend, build-backend]
-
-  - name: Run tests
-    run: npm test
-```
-
-## `jobs.<job_id>.steps[*].wait-all`
-
-Pauses the job until all active background steps complete. This is useful when several background steps are running and you want them all to finish before continuing. Like `wait`, the `wait-all` step fails if any of the background steps it waits on failed, unless you set [`continue-on-error`](#jobsjob_idstepscontinue-on-error) to `true`.
-
-The `wait-all` keyword takes no arguments.
-
-### Example: Waiting for all background steps
-
-```yaml
-steps:
-  - name: Start database
-    id: db
-    run: docker run -d postgres:15
-    background: true
-
-  - name: Start cache
-    id: cache
-    run: docker run -d redis:7
-    background: true
-
-  - name: Run integration tests
-    run: npm run test:integration
-
-  - name: Wait for all services to stop
-    wait-all:
-```
-
-## `jobs.<job_id>.steps[*].cancel`
-
-Gracefully terminates a running background step. The runner sends the step's process a termination signal (`SIGTERM`) so it can clean up, and forcibly stops it (`SIGKILL`) if it does not exit within a short grace period. The `cancel` keyword targets a single background step by its `id`.
-
-### Example: Canceling a background step
-
-```yaml
-steps:
-  - name: Start long-running monitor
-    id: monitor
-    run: ./scripts/monitor.sh
-    background: true
-
-  - name: Run the main task
-    run: npm test
-
-  - name: Stop the monitor
-    cancel: monitor
-```
-
-## `jobs.<job_id>.steps[*].parallel`
-
-Runs a group of steps concurrently, then waits for all of them to finish before continuing. The `parallel` keyword is shorthand: every step in the group runs as a background step, with an implicit `wait` at the end of the group. Use it when you have an independent group of steps that can run at the same time and you don't need to reference them individually.
-
-Use `parallel` when you have a self-contained group of steps that should all finish before the job moves on, such as building several components at once. Use [`background`](#jobsjob_idstepsbackground) when you need finer control: starting a long-running process (like a server or database) that stays up while later steps run, referencing a specific step with [`wait`](#jobsjob_idstepswait) or [`cancel`](#jobsjob_idstepscancel), or interleaving background work with other steps. In short, `parallel` is more limited but more convenient for the "run this group at once" case, while `background` is the general-purpose primitive.
-
-Each step in the group is subject to the same 10-step concurrency limit as other background steps.
-
-### Example: Running steps in parallel
-
-```yaml
-steps:
-  - uses: {% data reusables.actions.action-checkout %}
-
-  - parallel:
-      - name: Build frontend
-        run: npm run build:frontend
-
-      - name: Build backend
-        run: npm run build:backend
-
-      - name: Build docs
-        run: npm run build:docs
-
-  - name: Run tests after all builds complete
-    run: npm test
-```
-
-The group above is equivalent to declaring each step with `background: true` followed by a `wait` step.
-
-{% endif %}
-
 ## `jobs.<job_id>.timeout-minutes`
 
 The maximum number of minutes to let a job run before {% data variables.product.prodname_dotcom %} automatically cancels it. Default: 360

content/actions/tutorials/migrate-to-github-actions/manual-migrations/migrate-from-jenkins.md

@@ -76,7 +76,7 @@ Jenkins uses directives to manage _Declarative Pipelines_. These directives defi
 
 ### Parallel job processing
 
-{% ifversion actions-nga %}Jenkins can run the `stages` and `steps` in parallel. {% data variables.product.prodname_actions %} runs jobs in parallel and can also run steps concurrently within a job using step-level syntax. For more information, see [AUTOTITLE](/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsbackground).{% else %}Jenkins can run the `stages` and `steps` in parallel, while {% data variables.product.prodname_actions %} currently only runs jobs in parallel.{% endif %}
+Jenkins can run the `stages` and `steps` in parallel, while {% data variables.product.prodname_actions %} currently only runs jobs in parallel.
 
 | Jenkins Parallel | {% data variables.product.prodname_actions %} |
 | ------------- | ------------- |

content/copilot/how-tos/copilot-cli/cli-getting-started.md

@@ -42,7 +42,7 @@ Use one of these commands:
 * **macOS/Linux (Homebrew)**
 
   ```bash copy
-  brew install --cask copilot-cli
+  brew install copilot-cli
   ```
 
 ## Starting the CLI for the first time

content/copilot/how-tos/copilot-cli/set-up-copilot-cli/authenticate-copilot-cli.md

@@ -194,7 +194,3 @@ To revoke the OAuth app authorization on {% data variables.product.github %} and
    1. Click **Settings**.
 1. In the left sidebar, click **Applications**.
 1. Under **Authorized OAuth Apps**, click {% octicon "kebab-horizontal" aria-label="The horizontal kebab icon" %} next to **GitHub CLI** to expand the menu and select **Revoke**.
-
-## Next steps
-
-If you run into authentication problems, see [AUTOTITLE](/copilot/how-tos/copilot-cli/set-up-copilot-cli/troubleshoot-copilot-cli-auth).

content/copilot/how-tos/copilot-cli/set-up-copilot-cli/install-copilot-cli.md

@@ -72,13 +72,13 @@ winget install GitHub.Copilot.Prerelease
 ### Installing with Homebrew (macOS and Linux)
 
 ```shell copy
-brew install --cask copilot-cli
+brew install copilot-cli
 ```
 
 To install the prerelease version:
 
 ```shell copy
-brew install --cask copilot-cli@prerelease
+brew install copilot-cli@prerelease
 ```
 
 ### Installing with the install script (macOS and Linux)

data/tables/supported-code-languages.yml

@@ -41,15 +41,15 @@ features:
 languages:
   C:
     copilot: 'supported'
-    codeNavigation: 'not-supported'
+    codeNavigation: 'supported'
     codeScanning: 'supported'
     depGraph: 'not-supported'
     depUpdates: 'not-supported'
     actions: 'supported'
     packages: 'not-supported'
   C++:
     copilot: 'supported'
-    codeNavigation: 'not-supported'
+    codeNavigation: 'supported'
     codeScanning: 'supported'
     depGraph: 'not-supported'
     depUpdates: 'not-supported'

package.json

@@ -80,7 +80,6 @@
     "prettier-check": "prettier -c \"**/*.{ts,tsx,scss,yml,yaml}\"",
     "prevent-pushes-to-main": "tsx src/workflows/prevent-pushes-to-main.ts",
     "purge-fastly": "tsx src/workflows/purge-fastly.ts",
-    "purge-fastly-changed-content": "tsx src/workflows/purge-fastly-changed-content.ts",
     "readability-report": "tsx src/workflows/experimental/readability-report.ts",
     "ready-for-docs-review": "tsx src/workflows/ready-for-docs-review.ts",
     "release-banner": "tsx src/ghes-releases/scripts/release-banner.ts",