Add row headers to tables (#35685)

lecoursen · Peter Bengtsson · web-flow · commit 468dc59bb6e8 · 2023-03-27T13:17:43.000Z
Co-authored-by: Peter Bengtsson &lt;peterbe@github.com&gt;
diff --git a/content/actions/automating-builds-and-tests/building-and-testing-powershell.md b/content/actions/automating-builds-and-tests/building-and-testing-powershell.md
@@ -24,7 +24,7 @@ shortTitle: Build & test PowerShell
 
 This guide shows you how to use PowerShell for CI. It describes how to use Pester, install dependencies, test your module, and publish to the PowerShell Gallery.
 
-{% data variables.product.prodname_dotcom %}-hosted runners have a tools cache with pre-installed software, which includes PowerShell and Pester. 
+{% data variables.product.prodname_dotcom %}-hosted runners have a tools cache with pre-installed software, which includes PowerShell and Pester.
 
 {% ifversion ghae %}
 {% data reusables.actions.self-hosted-runners-software %}
@@ -71,9 +71,9 @@ jobs:
 * `run: Test-Path resultsfile.log` - Check whether a file called `resultsfile.log` is present in the repository's root directory.
 * `Should -Be $true` - Uses Pester to define an expected result. If the result is unexpected, then {% data variables.product.prodname_actions %} flags this as a failed test. For example:
 
-  
+
   ![Screenshot of a workflow run failure for a Pester test. Test reports "Expected $true, but got $false" and "Error: Process completed with exit code 1."](/assets/images/help/repository/actions-failed-pester-test-updated.png)
-  
+
 
 * `Invoke-Pester Unit.Tests.ps1 -Passthru` - Uses Pester to execute tests defined in a file called `Unit.Tests.ps1`. For example, to perform the same test described above, the `Unit.Tests.ps1` will contain the following:
   ```
@@ -88,12 +88,16 @@ jobs:
 
 The table below describes the locations for various PowerShell modules in each {% data variables.product.prodname_dotcom %}-hosted runner.
 
+{% rowheaders %}
+
 || Ubuntu | macOS | Windows |
 |------|-------|------|----------|
 |**PowerShell system modules** |`/opt/microsoft/powershell/7/Modules/*`|`/usr/local/microsoft/powershell/7/Modules/*`|`C:\program files\powershell\7\Modules\*`|
 |**PowerShell add-on modules**|`/usr/local/share/powershell/Modules/*`|`/usr/local/share/powershell/Modules/*`|`C:\Modules\*`|
 |**User-installed modules**|`/home/runner/.local/share/powershell/Modules/*`|`/Users/runner/.local/share/powershell/Modules/*`|`C:\Users\runneradmin\Documents\PowerShell\Modules\*`|
 
+{% endrowheaders %}
+
 ## Installing dependencies
 
 {% data variables.product.prodname_dotcom %}-hosted runners have PowerShell 7 and Pester installed. You can use `Install-Module` to install additional dependencies from the PowerShell Gallery before building and testing your code.
diff --git a/content/actions/automating-builds-and-tests/building-and-testing-python.md b/content/actions/automating-builds-and-tests/building-and-testing-python.md
@@ -89,12 +89,16 @@ Using the `setup-python` action is the recommended way of using Python with {% d
 
 The table below describes the locations for the tools cache in each {% data variables.product.prodname_dotcom %}-hosted runner.
 
+{% rowheaders %}
+
 || Ubuntu | Mac | Windows |
 |------|-------|------|----------|
 |**Tool Cache Directory** |`/opt/hostedtoolcache/*`|`/Users/runner/hostedtoolcache/*`|`C:\hostedtoolcache\windows\*`|
 |**Python Tool Cache**|`/opt/hostedtoolcache/Python/*`|`/Users/runner/hostedtoolcache/Python/*`|`C:\hostedtoolcache\windows\Python\*`|
 |**PyPy Tool Cache**|`/opt/hostedtoolcache/PyPy/*`|`/Users/runner/hostedtoolcache/PyPy/*`|`C:\hostedtoolcache\windows\PyPy\*`|
 
+{% endrowheaders %}
+
 If you are using a self-hosted runner, you can configure the runner to use the `setup-python` action to manage your dependencies. For more information, see [using setup-python with a self-hosted runner](https://github.com/actions/setup-python#using-setup-python-with-a-self-hosted-runner) in the `setup-python` README.
 
 {% data variables.product.prodname_dotcom %} supports semantic versioning syntax. For more information, see "[Using semantic versioning](https://docs.npmjs.com/about-semantic-versioning#using-semantic-versioning-to-specify-update-types-your-package-can-accept)" and the "[Semantic versioning specification](https://semver.org/)."
@@ -372,7 +376,7 @@ jobs:
 
 ## Publishing to package registries
 
-You can configure your workflow to publish your Python package to a package registry once your CI tests pass. This section demonstrates how you can use {% data variables.product.prodname_actions %} to upload your package to PyPI each time you [publish a release](/repositories/releasing-projects-on-github/managing-releases-in-a-repository). 
+You can configure your workflow to publish your Python package to a package registry once your CI tests pass. This section demonstrates how you can use {% data variables.product.prodname_actions %} to upload your package to PyPI each time you [publish a release](/repositories/releasing-projects-on-github/managing-releases-in-a-repository).
 
 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 "[AUTOTITLE](/actions/security-guides/encrypted-secrets)."
 
diff --git a/content/actions/creating-actions/about-custom-actions.md b/content/actions/creating-actions/about-custom-actions.md
@@ -35,12 +35,16 @@ Actions can run directly on a machine or in a Docker container. You can define a
 
 You can build Docker container, JavaScript, and composite actions. Actions require a metadata file to define the inputs, outputs and main entrypoint for your action. The metadata filename must be either `action.yml` or `action.yaml`. For more information, see "[AUTOTITLE](/actions/creating-actions/metadata-syntax-for-github-actions)."
 
+{% rowheaders %}
+
 | Type | Linux | macOS | Windows |
 | ---- | ----- | ----- | -------- |
 | Docker container | {% octicon "check" aria-label="Supported" %} | {% octicon "x" aria-label="Not supported" %} | {% octicon "x" aria-label="Not supported" %} |
 | JavaScript | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} |
 | Composite Actions | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} |
 
+{% endrowheaders %}
+
 ### Docker container actions
 
 Docker containers package the environment with the {% data variables.product.prodname_actions %} code. This creates a more consistent and reliable unit of work because the consumer of the action does not need to worry about the tools or dependencies.
diff --git a/content/actions/hosting-your-own-runners/autoscaling-with-self-hosted-runners.md b/content/actions/hosting-your-own-runners/autoscaling-with-self-hosted-runners.md
@@ -28,13 +28,17 @@ The following repositories have detailed instructions for setting up these autos
 
 Each solution has certain specifics that may be important to consider.
 
-| **Features** | **actions-runner-controller** | **terraform-aws-github-runner** |
+{% rowheaders %}
+
+| | actions-runner-controller | terraform-aws-github-runner |
 | :--- | :--- | :--- |
 | Runtime | Kubernetes | Linux and Windows VMs |
 | Supported Clouds | Azure, Amazon Web Services, Google Cloud Platform, on-premises | Amazon Web Services |
 | Where runners can be scaled | Enterprise, organization, and repository levels. By runner label and runner group. | Organization and repository levels. By runner label and runner group. |
 | How runners can be scaled | Webhook events, Scheduled, Pull-based | Webhook events, Scheduled (org-level runners only) |
 
+{% endrowheaders %}
+
 ## Using ephemeral runners for autoscaling
 
 {% data variables.product.prodname_dotcom %} recommends implementing autoscaling with ephemeral self-hosted runners; autoscaling with persistent self-hosted runners is not recommended. In certain cases, {% data variables.product.prodname_dotcom %} cannot guarantee that jobs are not assigned to persistent runners while they are shut down. With ephemeral runners, this can be guaranteed because {% data variables.product.prodname_dotcom %} only assigns one job to a runner.
diff --git a/content/actions/security-guides/automatic-token-authentication.md b/content/actions/security-guides/automatic-token-authentication.md
@@ -77,6 +77,8 @@ For information about the API endpoints {% data variables.product.prodname_githu
 
 The following table shows the permissions granted to the `GITHUB_TOKEN` by default. People with admin permissions to an {% ifversion not ghes %}enterprise, organization, or repository,{% else %}organization or repository{% endif %} can set the default permissions to be either permissive or restricted. For information on how to set the default permissions for the `GITHUB_TOKEN` for your enterprise, organization, or repository, see "[AUTOTITLE](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#enforcing-a-policy-for-workflow-permissions-in-your-enterprise)," "[AUTOTITLE](/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#setting-the-permissions-of-the-github_token-for-your-organization)," or "[AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#setting-the-permissions-of-the-github_token-for-your-repository)."
 
+{% rowheaders %}
+
 | Scope         | Default access<br>(permissive) | Default access<br>(restricted) | Maximum access for<br>pull requests from<br>public forked repositories [1] |
 |---------------|-----------------------------|-----------------------------|--------------------------------|
 | actions       | read/write  | none | read |
@@ -93,6 +95,8 @@ The following table shows the permissions granted to the `GITHUB_TOKEN` by defau
 | security-events     | read/write | none | read |
 | statuses      | read/write  | none | read |
 
+{% endrowheaders %}
+
 [1] Private repositories can control if pull requests from forks can run workflows, and configure the permissions assigned to `GITHUB_TOKEN`. For more information, see "[AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-forks-of-private-repositories)."
 
 {% data reusables.actions.workflow-runs-dependabot-note %}
diff --git a/content/apps/creating-github-apps/creating-github-apps/differences-between-github-apps-and-oauth-apps.md b/content/apps/creating-github-apps/creating-github-apps/differences-between-github-apps-and-oauth-apps.md
@@ -73,6 +73,8 @@ An _authorized_ OAuth App has access to all of the user's or organization owner'
 
 Unlike OAuth apps, GitHub Apps have targeted permissions that allow them to request access only to what they need. For example, a Continuous Integration (CI) GitHub App can request read access to repository content and write access to the status API. Another GitHub App can have no read or write access to code but still have the ability to manage issues, labels, and milestones. OAuth Apps can't use granular permissions.
 
+{% rowheaders %}
+
 | Access | GitHub Apps (`read` or `write` permissions) | OAuth Apps |
 | ------ | ----- | ----------- |
 | **For access to public repositories** | Public repository needs to be chosen during installation. | `public_repo` scope. |
@@ -83,6 +85,8 @@ Unlike OAuth apps, GitHub Apps have targeted permissions that allow them to requ
 | **For access to deployments and deployment statuses** | Deployments | `repo_deployment` scope. |
 | **To receive events via a webhook** | A GitHub App includes a webhook by default. | `write:repo_hook` or `write:org_hook` scope. |
 
+{% endrowheaders %}
+
 ## Repository discovery
 
 | GitHub Apps | OAuth Apps |
diff --git a/content/billing/managing-billing-for-github-packages/about-billing-for-github-packages.md b/content/billing/managing-billing-for-github-packages/about-billing-for-github-packages.md
@@ -32,6 +32,8 @@ If you purchased {% data variables.product.prodname_enterprise %} through a Micr
 
 Data transfer resets every month, while storage usage does not.
 
+{% rowheaders %}
+
 Product | Storage | Data transfer (per month)
 ------- | ------- | ---------
 {% data variables.product.prodname_free_user %} | 500MB | 1GB
@@ -40,13 +42,19 @@ Product | Storage | Data transfer (per month)
 {% data variables.product.prodname_team %} | 2GB | 10GB
 {% data variables.product.prodname_ghe_cloud %} | 50GB | 100GB
 
+{% endrowheaders %}
+
 All data transferred out, when triggered by {% data variables.product.prodname_actions %}, and data transferred in from any source is free. We determine you are downloading packages using {% data variables.product.prodname_actions %} when you log in to {% data variables.product.prodname_registry %} using a `GITHUB_TOKEN`.
 
+{% rowheaders %}
+
 ||Hosted|Self-Hosted|
 |-|-|-|
 |Access using a `GITHUB_TOKEN`|Free|Free|
 |Access using a {% data variables.product.pat_generic %}|Free|Paid|
 
+{% endrowheaders %}
+
 Storage usage is shared with build artifacts produced by {% data variables.product.prodname_actions %} for repositories owned by your account. For more information, see "[AUTOTITLE](/billing/managing-billing-for-github-actions/about-billing-for-github-actions)."
 
 {% data variables.product.prodname_dotcom %} charges usage to the account that owns the repository where the package is published. If your account's usage surpasses these limits and you have set a spending limit above $0 USD, you will pay $0.008 USD per GB of storage per day and $0.50 USD per GB of data transfer.
diff --git a/content/code-security/code-scanning/integrating-with-code-scanning/sarif-support-for-code-scanning.md b/content/code-security/code-scanning/integrating-with-code-scanning/sarif-support-for-code-scanning.md
@@ -106,6 +106,8 @@ For each `gzip`-compressed SARIF file, SARIF upload supports a maximum size of 1
 
 {% ifversion fpt or ghec or ghes > 3.8 %}
 
+{% rowheaders %}
+
 | **SARIF data** | **Maximum values** | **Additional limits** |
 |----------------|:------------------:|-----------------------|
 | Runs per file | 20 | None |
@@ -116,8 +118,12 @@ For each `gzip`-compressed SARIF file, SARIF upload supports a maximum size of 1
 | Location per result |  1,000 | Only 100 locations will be included. |
 | Tags per rule |  20 | Only 10 tags will be included. |
 
+{% endrowheaders %}
+
 {% elsif ghes < 3.9 %}
 
+{% rowheaders %}
+
 | **SARIF data** | **Maximum values** | **Additional limits** |
 |----------------|:------------------:|-----------------------|
 | Runs per file | 15 |  None |
@@ -128,8 +134,12 @@ For each `gzip`-compressed SARIF file, SARIF upload supports a maximum size of 1
 | Location per result | 1,000 | Only 100 locations will be included. |
 | Tags per rule | 20 | Only 10 tags will be included. |
 
+{% endrowheaders %}
+
 {% else %}
 
+{% rowheaders %}
+
 | **SARIF data** | **Maximum values** | **Additional limits** |
 |----------------|:------------------:|-----------------------|
 | Runs per file | 15 | None |
@@ -138,6 +148,8 @@ For each `gzip`-compressed SARIF file, SARIF upload supports a maximum size of 1
 | Thread Flow Locations per result | 10,000 | Only the top 1,000 Thread Flow Locations will be included, using prioritization. |
 | Location per result |  1,000 | Only 100 locations will be included. | None |
 
+{% endrowheaders %}
+
 {% endif %}
 
 ## Supported SARIF output file properties
diff --git a/content/codespaces/the-githubdev-web-based-editor.md b/content/codespaces/the-githubdev-web-based-editor.md
@@ -48,6 +48,8 @@ You can open any {% data variables.product.prodname_dotcom %} repository in {% d
 
 Both {% data variables.codespaces.serverless %} and {% data variables.product.prodname_github_codespaces %} allow you to edit your code straight from your repository. However, both have slightly different benefits, depending on your use case.
 
+{% rowheaders %}
+
 || {% data variables.codespaces.serverless %} | {% data variables.product.prodname_github_codespaces %}|
 |-|----------------|---------|
 | **Cost** | Free.      | Free monthly quota of usage for personal accounts. For information on pricing, see "[AUTOTITLE](/free-pro-team@latest/billing/managing-billing-for-github-codespaces/about-billing-for-github-codespaces#about-github-codespaces-pricing)."|
@@ -57,6 +59,8 @@ Both {% data variables.codespaces.serverless %} and {% data variables.product.pr
 | **Terminal access** | None. | {% data variables.product.prodname_github_codespaces %} provides a common set of tools by default, meaning that you can use the Terminal exactly as you would in your local environment.|
 | **Extensions**  | Only a subset of extensions that can run in the web will appear in the Extensions View and can be installed. For more information, see "[Using extensions](#using-extensions)."| With {% data variables.product.prodname_github_codespaces %}, you can use most extensions from the {% data variables.product.prodname_vscode_marketplace %}.|
 
+{% endrowheaders %}
+
 ### Continue working on {% data variables.product.prodname_codespaces %}
 
 You can start your workflow in {% data variables.codespaces.serverless %} and continue working on a codespace. If you try to access the Run and Debug View or the Terminal, you'll be notified that they are not available in {% data variables.codespaces.serverless %}.
@@ -88,7 +92,7 @@ Because {% data variables.codespaces.serverless %} uses the GitHub Repositories
 
 1. In the text box, type a commit message describing the change you've made.
 
-   ![Screenshot of the "Source control" side bar with a commit message entered into the text box above the "Commit" button.](/assets/images/help/codespaces/githubdotdev-codespaces-commit-message.png)  
+   ![Screenshot of the "Source control" side bar with a commit message entered into the text box above the "Commit" button.](/assets/images/help/codespaces/githubdotdev-codespaces-commit-message.png)
 
 1. Click **Commit & Push**.
 
diff --git a/content/get-started/learning-about-github/about-github-advanced-security.md b/content/get-started/learning-about-github/about-github-advanced-security.md
@@ -38,11 +38,16 @@ A {% data variables.product.prodname_GH_advanced_security %} license provides th
 {% ifversion fpt or ghec %}
 The table below summarizes the availability of {% data variables.product.prodname_GH_advanced_security %} features for public and private repositories.
 
+{% rowheaders %}
+
 | | Public repository | Private repository <br>without {% data variables.product.prodname_advanced_security %} | Private repository <br>with {% data variables.product.prodname_advanced_security %} |
 | --- | --- | --- | --- |
 | Code scanning     | {% octicon "check" aria-label="Yes" %} | {% octicon "x" aria-label="No" %} | {% octicon "check" aria-label="Yes" %} |
 | Secret scanning   | {% octicon "check" aria-label="Yes" %} | {% octicon "x" aria-label="No" %} | {% octicon "check" aria-label="Yes" %} |
 | Dependency review | {% octicon "check" aria-label="Yes" %} | {% octicon "x" aria-label="No" %} | {% octicon "check" aria-label="Yes" %} |
+
+{% endrowheaders %}
+
 {% endif %}
 
 For information about {% data variables.product.prodname_advanced_security %} features that are in development, see "[{% data variables.product.prodname_dotcom %} public roadmap](https://github.com/github/roadmap)." For an overview of all security features, see "[AUTOTITLE](/code-security/getting-started/github-security-features)."
diff --git a/content/support/learning-about-github-support/about-github-premium-support.md b/content/support/learning-about-github-support/about-github-premium-support.md
@@ -40,6 +40,8 @@ topics:
 
 There are two {% data variables.contact.premium_support %} plans: Premium and Premium Plus / {% data variables.product.microsoft_premium_plus_support_plan %}.
 
+{% rowheaders %}
+
 | | {% data variables.product.premium_support_plan %} | {% data variables.product.premium_plus_support_plan %} |
 |---|---|------|
 | Hours of operation | 24 x 7 | 24 x 7 |
@@ -55,6 +57,8 @@ Incident management | None | For Urgent priority tickets, as needed
 | Application upgrade assistance | None | By request |
 | Cloud planning | None | By request |
 
+{% endrowheaders %}
+
   {% note %}
 
   **Notes:**
diff --git a/data/reusables/copilot/differences-cfi-cfb-table.md b/data/reusables/copilot/differences-cfi-cfb-table.md
