Merge branch 'main' into update_jfrog_docs

Author: Sharra-writes

.github/ISSUE_TEMPLATE/for-docs-team-use-only.md

@@ -4,9 +4,9 @@ import coreLib from '@actions/core'
 import { type Octokit } from '@octokit/rest'
 import { CoreInject } from '@/links/scripts/action-injections'
 
-import github from '#src/workflows/github.ts'
-import { getActionContext } from '#src/workflows/action-context.ts'
-import { boolEnvVar } from '#src/workflows/get-env-inputs.ts'
+import github from '@/workflows/github'
+import { getActionContext } from '@/workflows/action-context'
+import { boolEnvVar } from '@/workflows/get-env-inputs'
 
 type Options = {
   addLabels?: string[]

.github/actions/labeler/labeler.ts

@@ -1,17 +1,107 @@
 This documentation repository consists mainly of content written in Markdown format. These files are converted into HTML for displaying on a website. Most Markdown files become a single article on the documentation site. Other files contain reusable content which is inserted into multiple articles. The repository also contains YAML files (e.g. for variable text), image files, JavaScript/TypeScript files, etc.
 
+## Content guidelines
+
+### Bullet lists
+
+The bulleted points in a bullet list should always be denoted in Markdown using an asterisk, not a hyphen.
+
 ### Using variables
 
-Within Markdown files, with the exception of the `title` field in the metadata at the start of a file, always use the Liquid syntax variables rather than text if a variable has been defined for that text. For example:
+Within Markdown files, with the exception of the `title` field in the metadata at the start of a file, **always use the Liquid syntax variables rather than text** if a variable has been defined for that text. This ensures consistency and makes it easier to update product names globally.
+
+**Important**: Variables must be used in all content, including reusable content, data files, and regular articles. The only exception is the `title` field in frontmatter metadata.
+
+For example:
 
-| Use this variable | Don't use this text | File where variable is defined |
-| --- | --- | --- |
-| `{% data variables.product.prodname_dotcom %}` | GitHub | data/variables/product.yml |
-| `{% data variables.product.prodname_ghe_server %}` | GitHub Enterprise Server | data/variables/product.yml | 
-| `{% data variables.product.prodname_copilot_short %}` | Copilot | data/variables/product.yml | 
-| `{% data variables.product.prodname_copilot %}` | GitHub Copilot | data/variables/product.yml | 
-| `{% data variables.copilot.copilot_code-review_short %}` | Copilot code review | data/variables/copilot.yml | 
-| `{% data variables.enterprise.prodname_managed_user %}` | managed user account | data/variables/enterprise.yml | 
-| `{% data variables.code-scanning.codeql_workflow %}` | CodeQL analysis workflow | data/variables/code-scanning.yml | 
+| Use this variable                                        | Don't use this text      | File where variable is defined   |
+| -------------------------------------------------------- | ------------------------ | -------------------------------- |
+| `{% data variables.product.github %}`                    | GitHub                   | data/variables/product.yml       |
+| `{% data variables.product.prodname_ghe_server %}`       | GitHub Enterprise Server | data/variables/product.yml       |
+| `{% data variables.product.prodname_copilot_short %}`    | Copilot                  | data/variables/product.yml       |
+| `{% data variables.product.prodname_copilot %}`          | GitHub Copilot           | data/variables/product.yml       |
+| `{% data variables.copilot.copilot_code-review_short %}` | Copilot code review      | data/variables/copilot.yml       |
+| `{% data variables.enterprise.prodname_managed_user %}`  | managed user account     | data/variables/enterprise.yml    |
+| `{% data variables.code-scanning.codeql_workflow %}`     | CodeQL analysis workflow | data/variables/code-scanning.yml |
 
 There are many more variables. These are stored in various YAML files within the `data/variables` directory.
+
+**How to find variables**: Check the `data/variables` directory for existing variables before writing hardcoded text. Common variable files include:
+
+* `data/variables/product.yml` - Product names and variations
+* `data/variables/copilot.yml` - Copilot-specific terms
+* `data/variables/enterprise.yml` - Enterprise-specific terms
+* `data/variables/code-scanning.yml` - Code scanning terms
+
+### Reusable text
+
+Reusables are long strings of reusable text, such as paragraphs or procedural lists, that are referenced in multiple content files. This makes it easier for us to maintain content and ensure that it is accurate across all files where the content is needed.
+
+Each reusable lives in its own Markdown file. The path and filename of each reusable determines what its path will be in the data object. For example, a file named `/data/reusables/foo/bar.md` will be accessible as `{% data reusables.foo.bar %}` in articles.
+
+Examples where you should create a reusable:
+
+* You are documenting a new feature for a public preview. You need to create a note to display in all new articles about the new feature. Create a new reusable for the note and use it in all articles where it is needed.
+* You are documenting billing for a new feature and need to briefly mention how the feature is billed and link to content about billing in several articles. Create a new reusable with the brief mention and a link to the content on billing. Aim to use the reusable in all places where you want to mention billing for the feature.
+
+### Links to other articles
+
+`[AUTOTITLE]` is the **only correct way** to specify the title of a linked article when that article is another page on the docs.github.com site.
+
+You can replace the placeholder link text `[AUTOTITLE]` only when linking to an anchor in the same article or when linking to an anchor in another article and the actual article title would be confusing.
+
+Never use the `{% link %}` Liquid tag for internal documentation links. The `[AUTOTITLE]` placeholder automatically pulls the correct title and ensures links remain valid when titles change.
+
+Examples:
+
+* ✅ Correct: `For more information, see [AUTOTITLE](/copilot/using-github-copilot).`
+* ❌ Incorrect: `For more information, see [Using GitHub Copilot](/copilot/using-github-copilot).`
+* ❌ Incorrect: `For more information, see {% link /copilot/using-github-copilot %}.`
+
+### Creating a pull request
+
+When creating a pull request as a result of a request to do so in Copilot Chat, the first line of the PR description should **always** be the following (in italics):
+
+`_This pull request was created as a result of the following prompt in Copilot Chat._`
+
+Then, within a collapsed section, quote the original prompt from Copilot Chat:
+
+```markdown
+<details>
+<summary>Original prompt - submitted by @GITHUB-USER-ID</summary>
+
+> [Original prompt text here]
+
+</details>
+```
+
+This helps reviewers understand the context and intent behind the automated changes.
+
+## Development and testing guidelines
+
+### Content changes
+
+Before committing content changes, always:
+
+1. **Use the content linter** to validate content: `npm run lint-content -- --paths <file-paths>`
+2. **Check for proper variable usage** in your content
+3. **Verify [AUTOTITLE] links** point to existing articles
+4. **Run tests** on changed content: `npm run test -- src/content-render/tests/render-changed-and-deleted-files.js`
+
+### Script and code changes
+
+For TypeScript, JavaScript, and SCSS files:
+
+1. **Run Prettier** to check formatting: `npm run prettier-check`
+2. **Run the linter**: `npm run lint`
+3. **Run TypeScript checks**: `npm run tsc`
+4. **Run relevant tests**: `npm test`
+
+### Environment setup
+
+When testing changes in your development environment:
+
+1. Install dependencies: `npm ci`
+2. For content changes, ensure the content linter runs successfully
+3. For script changes, ensure all formatting and linting checks pass
+4. Always verify your changes don't break existing functionality

.github/copilot-instructions.md

@@ -48,6 +48,7 @@ jobs:
         with:
           repo-token: ${{ secrets.GITHUB_TOKEN }}
           stale-pr-message: 'This is a gentle bump for the docs team that this PR is waiting for review.'
+          days-before-issue-stale: -1
           days-before-pr-stale: 14
           days-before-pr-close: -1 # Never close
           remove-stale-when-updated: false

.github/workflows/triage-stale-check.yml

@@ -19,7 +19,7 @@ You can also contribute by creating a local environment or opening a Codespace.
 
 <img alt="Contribution call-to-action" src="./contributing/images/contribution_cta.png" width="400">
 
-For more complex contributions, please open an issue using the most appropriate [issue template](https://github.com/github/docs/issues/new/choose) to describe the changes you'd like to see.
+For more complex contributions, please [open an issue in the docs-content repo](https://github.com/github/docs-content/issues/new/choose) describing the changes you'd like to see.
 
 If you're looking for a way to contribute, you can scan through our [help wanted board](https://github.com/github/docs/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) to find open issues already approved for work.
 

README.md

@@ -65,6 +65,13 @@ To see repositories that you're watching, go to your [watching page](https://git
 
 You can configure notifications for a repository on the repository page, or on your watching page.
 
+{% ifversion fpt or ghec %}
+
+> [!NOTE]
+> You can watch a maximum of 10,000 repositories.
+
+{% endif %}
+
 ### About custom notifications
 
 You can customize notifications for a repository. For example, you can choose to only be notified when updates to one or more types of events ({% data reusables.notifications-v2.custom-notification-types %}) happen within a repository, or ignore all notifications for a repository. For more information, see [Configuring your watch settings for an individual repository](#configuring-your-watch-settings-for-an-individual-repository) below.

content/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications.md

@@ -59,3 +59,12 @@ By default, {% data variables.product.github %} syncs with your system-level pre
 1. Under "Motion", manage settings for motion.
 
    * To control how {% data variables.product.github %} displays animated images, under "Autoplay animated images", select **Sync with system**, **Enabled**, or **Disabled**.
+
+## Managing appearance settings for better contrast
+
+You can customize contrast levels to improve visibility and meet accessibility needs.
+
+* If you're **not signed in**, click {% octicon "sliders" aria-hidden="true" aria-label="sliders" %} on the right in the top navigation bar to access the contrast settings.
+* If you're **signed in**, click **{% octicon "paintbrush" aria-hidden="true" aria-label="paintbrush" %} Appearance** in the left sidebar of your user settings. Under "Contrast", you can access the contrast settings.
+
+You can toggle the switch for "Increase contrast" to enable or disable high contrast mode. You can also choose between light and dark mode, or both, based on your system settings.

content/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-user-account-settings/managing-accessibility-settings.md

@@ -18,7 +18,7 @@ topics:
 
 {% data reusables.actions.actions-runner-controller-about-arc %}
 
-The following diagram illustrates the architecture of ARC's autoscaling runner scaleset mode.
+The following diagram illustrates the architecture of ARC's autoscaling runner scale set mode.
 
 > [!NOTE]
 > To view the following diagram in a larger size, see the [Autoscaling Runner Scale Sets mode](https://github.com/actions/actions-runner-controller/blob/master/docs/gha-runner-scale-set-controller/README.md#how-it-works) documentation in the Actions Runner Controller repository.
@@ -30,7 +30,7 @@ The following diagram illustrates the architecture of ARC's autoscaling runner s
 1. {% data variables.product.prodname_actions_runner_controller %} is installed using the supplied Helm charts, and the controller manager pod is deployed in the specified namespace. A new AutoScalingRunnerSet resource is deployed via the supplied Helm charts or a customized manifest file. The AutoScalingRunnerSet Controller calls GitHub's APIs to fetch the runner group ID that the runner scale set will belong to.
 1. The AutoScalingRunnerSet Controller calls the APIs one more time to either fetch or create a runner scale set in the {% data variables.product.prodname_actions %} service before creating the Runner ScaleSet Listener resource.
 1. A Runner ScaleSet Listener pod is deployed by the AutoScalingListener Controller. In this pod, the listener application connects to the {% data variables.product.prodname_actions %} Service to authenticate and establish an HTTPS long poll connection. The listener stays idle until it receives a `Job Available` message from the {% data variables.product.prodname_actions %} Service.
-1. When a workflow run is triggered from a repository, the {% data variables.product.prodname_actions %} Service dispatches individual job runs to the runners or runner scalesets where the `runs-on` key matches the name of the runner scaleset or labels of self-hosted runners.
+1. When a workflow run is triggered from a repository, the {% data variables.product.prodname_actions %} Service dispatches individual job runs to the runners or runner scale sets where the `runs-on` key matches the name of the runner scale set or labels of self-hosted runners.
 1. When the Runner ScaleSet Listener receives the `Job Available` message, it checks whether it can scale up to the desired count. If it can, the Runner ScaleSet Listener acknowledges the message.
 1. The Runner ScaleSet Listener uses a Service Account and a Role bound to that account to make an HTTPS call through the Kubernetes APIs to patch the Ephemeral RunnerSet resource with the number of desired replicas count.
 1. The Ephemeral RunnerSet attempts to create new runners and the EphemeralRunner Controller requests a Just-in-Time (JIT) configuration token to register these runners. The controller attempts to create runner pods. If the pod's status is `failed`, the controller retries up to 5 times. After 24 hours the {% data variables.product.prodname_actions %} Service unassigns the job if no runner accepts it.

content/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/about-actions-runner-controller.md

@@ -490,7 +490,7 @@ No output is expected for `run_script_step`.
    npm install && npm run bootstrap && npm run build-all
    ```
 
-When the resulting `index.js` is triggered by {% data variables.product.prodname_actions %}, it will run the customization commands defined in the JSON files. To trigger the `index.js`, you will need to add it your `ACTIONS_RUNNER_REQUIRE_JOB_CONTAINER` environment variable, as described in the next section.
+When the resulting `index.js` is triggered by {% data variables.product.prodname_actions %}, it will run the customization commands defined in the JSON files. To trigger the `index.js`, you will need to add it to your `ACTIONS_RUNNER_REQUIRE_JOB_CONTAINER` environment variable, as described in the next section.
 
 ## Triggering the customization script
 

content/actions/hosting-your-own-runners/managing-self-hosted-runners/customizing-the-containers-used-by-jobs.md

@@ -348,7 +348,7 @@ You should also consider the environment of the self-hosted runner machines:
 * What sensitive information resides on the machine configured as a self-hosted runner? For example, private SSH keys, API access tokens, among others.
 * Does the machine have network access to sensitive services? For example, Azure or AWS metadata services. The amount of sensitive information in this environment should be kept to a minimum, and you should always be mindful that any user capable of invoking workflows has access to this environment.
 
-Some customers might attempt to partially mitigate these risks by implementing systems that automatically destroy the self-hosted runner after each job execution. However, this approach might not be as effective as intended, as there is no way to guarantee that a self-hosted runner only runs one job. Some jobs will use secrets as command-line arguments which can be seen by another job running on the same runner, such as `ps x -w`. This can lead to secret leakages.
+Some customers might attempt to partially mitigate these risks by implementing systems that automatically destroy the self-hosted runner after each job execution. However, this approach might not be as effective as intended, as there is no way to guarantee that a self-hosted runner only runs one job. Some jobs will use secrets as command-line arguments which can be seen by another job running on the same runner, such as `ps x -w`. This can lead to secret leaks.
 
 ### Using just-in-time runners
 
@@ -379,7 +379,7 @@ A self-hosted runner can be added to various levels in your {% data variables.pr
 
 ### Authenticating to your cloud provider
 
-If you are using {% data variables.product.prodname_actions %} to deploy to a cloud provider, or intend to use HashiCorp Vault for secret management, then its recommended that you consider using OpenID Connect to create short-lived, well-scoped access tokens for your workflow runs. For more information, see [AUTOTITLE](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect).
+If you are using {% data variables.product.prodname_actions %} to deploy to a cloud provider, or intend to use HashiCorp Vault for secret management, then it's recommended that you consider using OpenID Connect to create short-lived, well-scoped access tokens for your workflow runs. For more information, see [AUTOTITLE](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect).
 
 ## Auditing {% data variables.product.prodname_actions %} events