Merge branch 'main' into gha-hardening-pull-request-target

Author: Sharra-writes

.github/copilot-instructions.md

@@ -1,4 +1,44 @@
-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.
+This repository contains code to run the GitHub Docs site on docs.github.com, as well as the content that is displayed on the site. The code is written in JavaScript and TypeScript, and the content is primarily written in Markdown.
+
+Changes to files in `src/*` or files with `.ts` or `.js` extensions are likely code-related changes. Please follow the engineering guidelines below when making changes to these files.
+
+Changes to files in `content/*` and `data/*` are likely content-related changes. Content changes include updates to articles, reusable content, and data files that define variables used in articles. Please follow the content guidelines below when making changes to these files.
+
+## Engineering guidelines
+
+### Scripts
+
+All scripts can be found in `package.json`.
+
+To validate any code changes:
+   - `npm run tsc`
+   - `npm run build`
+   - `npm run prettier`
+   - `npm run lint`: you can include `-- --fix`
+
+To validate specific changes,
+  - `npm run test`: For all unit tests
+    - You can pass specific paths, e.g. `npm run test -- src/search/tests/ai-search-proxy`
+    - You can add `--silent=false` to include `console.log` debugging.
+  - `npm run build && npm run playwright-test -- playwright-rendering`: You need to build for changes outside of the test to be picked up. We use playwright for all rendering and end-to-end tests
+    - You can add `--ui` to keep open `localhost:4000` which can be viewed in a simple browser for debugging UI state.
+  - `npm run dev` to start the development server on `localhost:4000`.
+
+### Imports
+
+We use absolute imports, relative to the `src` directory, using the `@` symbol.
+
+For example, `getRedirect` which lives inn `src/redirects/lib/get-redirect.js` can be imported with `import getRedirect from '@/redirects/lib/get-redirect'`.
+
+The same rule applies for TypeScript (`.ts`) imports, e.g. `import type { GeneralSearchHit } from '@/search/types'`
+
+### Testing changes
+
+We use `vitest` to write unit tests. Tests live in their own files in the `tests` subdirectory of a source (src) directory, e.g. `src/search/tests/api-ai-search.ts`. 
+
+For integration tests, we can use the mock server in `src/tests/mocks/start-mock-server.ts` to mock exteneral requests. 
+
+For UI rendering tests, we use `playwright` and write tests in `src/fixtures/tests/playwright-rendering.spec.ts`
 
 ## Content guidelines
 
@@ -90,31 +130,11 @@ Then, within a collapsed section, quote the original prompt from Copilot Chat:
 
 This helps reviewers understand the context and intent behind the automated changes.
 
-## Development and testing guidelines
-
-### Content changes
+### Testing 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

Dockerfile

@@ -8,7 +8,7 @@
 # ---------------------------------------------------------------
 # To update the sha:
 # https://github.com/github/gh-base-image/pkgs/container/gh-base-image%2Fgh-base-noble
-FROM ghcr.io/github/gh-base-image/gh-base-noble:20250707-185623-g8becf904e AS base
+FROM ghcr.io/github/gh-base-image/gh-base-noble:20250709-201453-g6a417ef5f AS base
 
 # Install curl for Node install and determining the early access branch
 # Install git for cloning docs-early-access & translations repos

content/actions/concepts/overview/about-continuous-integration-with-github-actions.md renamed to content/actions/concepts/overview/continuous-integration.md

@@ -1,5 +1,5 @@
 ---
-title: About continuous integration with GitHub Actions
+title: Continuous integration
 intro: 'You can create custom continuous integration (CI) workflows directly in your {% data variables.product.prodname_dotcom %} repository with {% data variables.product.prodname_actions %}.'
 redirect_from:
   - /articles/about-continuous-integration
@@ -10,6 +10,7 @@ redirect_from:
   - /actions/automating-builds-and-tests/about-continuous-integration
   - /actions/about-github-actions/about-continuous-integration
   - /actions/about-github-actions/about-continuous-integration-with-github-actions
+  - /actions/concepts/overview/about-continuous-integration-with-github-actions
 versions:
   fpt: '*'
   ghes: '*'
@@ -44,13 +45,6 @@ In addition to helping you set up CI workflows for your project, you can use {%
 
 For a definition of common terms, see [AUTOTITLE](/actions/learn-github-actions/understanding-github-actions).
 
-## Workflow templates
+## Next steps
 
-{% data variables.product.github %} offers CI workflow templates for a variety of languages and frameworks.
-
-Browse the complete list of CI workflow templates offered by {% data variables.product.company_short %} in the {% ifversion fpt or ghec %}[actions/starter-workflows](https://github.com/actions/starter-workflows/tree/main/ci) repository{% else %} `actions/starter-workflows` repository on {% data variables.product.prodname_dotcom_the_website %}{% endif %}.
-
-## Further reading
-
-* [AUTOTITLE](/actions/use-cases-and-examples/building-and-testing){% ifversion fpt or ghec %}
-* [AUTOTITLE](/billing/managing-billing-for-github-actions){% endif %}
+{% data variables.product.github %} offers CI workflow templates for a variety of languages and frameworks. For tutorials on setting up continuous integration with these templates, see [AUTOTITLE](/actions/use-cases-and-examples/building-and-testing).

content/actions/concepts/overview/index.md

@@ -8,6 +8,6 @@ versions:
   ghec: '*'
 children:
   - /about-continuous-deployment-with-github-actions
-  - /about-continuous-integration-with-github-actions
+  - /continuous-integration
   - /usage-limits-billing-and-administration
 ---

content/actions/concepts/use-cases/deploying-with-github-actions.md

@@ -59,6 +59,8 @@ For more information, see [AUTOTITLE](/actions/using-workflows/events-that-trigg
 
 {% data reusables.actions.about-environments %}
 
+You can configure environments with protection rules and secrets. When a workflow job references an environment, the job won't start until all of the environment's protection rules pass. A job also cannot access secrets that are defined in an environment until all the deployment protection rules pass. To learn more, see [Using custom deployment protection rules](#using-custom-deployment-protection-rules) in this article.
+
 ## Using concurrency
 
 Concurrency ensures that only a single job or workflow using the same concurrency group will run at a time. You can use concurrency so that an environment has a maximum of one deployment in progress and one deployment pending at a time. For more information about concurrency, see [AUTOTITLE](/actions/using-jobs/using-concurrency).
@@ -142,6 +144,30 @@ Every workflow run generates a real-time graph that illustrates the run progress
 
 You can also view the logs of each workflow run and the history of workflow runs. For more information, see [AUTOTITLE](/actions/monitoring-and-troubleshooting-workflows/viewing-workflow-run-history).
 
+## Using required reviews in workflows
+
+Jobs that reference an environment configured with required reviewers will wait for an approval before starting. While a job is awaiting approval, it has a status of "Waiting". If a job is not approved within 30 days, it will automatically fail.
+
+For more information about environments and required approvals, see [AUTOTITLE](/actions/deployment/targeting-different-environments/managing-environments-for-deployment). For information about how to review deployments with the REST API, see [AUTOTITLE](/rest/actions/workflow-runs).
+
+## Using custom deployment protection rules
+
+{% data reusables.actions.custom-deployment-protection-rules-beta-note %}
+
+{% data reusables.actions.about-custom-deployment-protection-rules %}
+
+Custom deployment protection rules are powered by {% data variables.product.prodname_github_apps %} and run based on webhooks and callbacks. Approval or rejection of a workflow job is based on consumption of the `deployment_protection_rule` webhook. For more information, see [AUTOTITLE](/webhooks-and-events/webhooks/webhook-events-and-payloads#deployment_protection_rule) and [Approving or rejecting deployments](/actions/how-tos/managing-workflow-runs-and-deployments/managing-deployments/creating-custom-deployment-protection-rules#approving-or-rejecting-deployments).
+
+Once you have created a custom deployment protection rule and installed it on your repository, the custom deployment protection rule will automatically be available for all environments in the repository.
+
+Deployments to an environment can be approved or rejected based on the conditions defined in any external service like an approved ticket in an IT Service Management (ITSM) system, vulnerable scan result on dependencies, or stable health metrics of a cloud resource. The decision to approve or reject deployments is at the discretion of the integrating third-party application and the gating conditions you define in them. The following are a few use cases for which you can create a deployment protection rule.
+
+* ITSM & Security Operations: you can check for service readiness by validating quality, security, and compliance processes that verify deployment readiness.
+* Observability systems: you can consult monitoring or observability systems (Asset Performance Management Systems and logging aggregators, cloud resource health verification systems, etc.) for verifying the safety and deployment readiness.
+* Code quality & testing tools: you can check for automated tests on CI builds which need to be deployed to an environment.
+
+Alternatively, you can write your own protection rules for any of the above use cases or you can define any custom logic to safely approve or reject deployments from pre-production to production environments.
+
 ## Tracking deployments through apps
 
 {% ifversion fpt or ghec %}

content/actions/concepts/use-cases/using-github-actions-for-project-management.md

@@ -35,9 +35,7 @@ Workflows can do many things, such as commenting on an issue, adding or removing
 
 You can learn about using {% data variables.product.prodname_actions %} for project management by following these tutorials, which include example workflows that you can adapt to meet your needs.
 
-* [AUTOTITLE](/actions/managing-issues-and-pull-requests/adding-labels-to-issues){%- ifversion projects-v1 %}
-* [AUTOTITLE](/actions/managing-issues-and-pull-requests/removing-a-label-when-a-card-is-added-to-a-project-board-column)
-* [AUTOTITLE](/actions/managing-issues-and-pull-requests/moving-assigned-issues-on-project-boards){% endif %}
+* [AUTOTITLE](/actions/managing-issues-and-pull-requests/adding-labels-to-issues)
 * [AUTOTITLE](/actions/managing-issues-and-pull-requests/commenting-on-an-issue-when-a-label-is-added)
 * [AUTOTITLE](/actions/managing-issues-and-pull-requests/closing-inactive-issues)
 * [AUTOTITLE](/actions/managing-issues-and-pull-requests/scheduling-issue-creation)

content/actions/how-tos/managing-workflow-runs-and-deployments/managing-deployments/creating-custom-deployment-protection-rules.md

@@ -16,25 +16,11 @@ redirect_from:
   - /actions/managing-workflow-runs-and-deployments/managing-deployments/creating-custom-deployment-protection-rules
 ---
 
-{% data reusables.actions.custom-deployment-protection-rules-beta-note %}
-
-## About custom deployment protection rules
-
-{% data reusables.actions.about-custom-deployment-protection-rules %}
-
-Custom deployment protection rules are powered by {% data variables.product.prodname_github_apps %} and run based on webhooks and callbacks. Approval or rejection of a workflow job is based on consumption of the `deployment_protection_rule` webhook. For more information, see [AUTOTITLE](/webhooks-and-events/webhooks/webhook-events-and-payloads#deployment_protection_rule) and [Approving or rejecting deployments](#approving-or-rejecting-deployments).
+## Prerequisites
 
-Once you have created a custom deployment protection rule and installed it on your repository, the custom deployment protection rule will automatically be available for all environments in the repository.
-
-## Using custom deployment protection rules to approve or reject deployments
-
-Deployments to an environment can be approved or rejected based on the conditions defined in any external service like an approved ticket in an IT Service Management (ITSM) system, vulnerable scan result on dependencies, or stable health metrics of a cloud resource. The decision to approve or reject deployments is at the discretion of the integrating third-party application and the gating conditions you define in them. The following are a few use cases for which you can create a deployment protection rule.
-
-* ITSM & Security Operations: you can check for service readiness by validating quality, security, and compliance processes that verify deployment readiness.
-* Observability systems: you can consult monitoring or observability systems (Asset Performance Management Systems and logging aggregators, cloud resource health verification systems, etc.) for verifying the safety and deployment readiness.
-* Code quality & testing tools: you can check for automated tests on CI builds which need to be deployed to an environment.
+{% data reusables.actions.custom-deployment-protection-rules-beta-note %}
 
-Alternatively, you can write your own protection rules for any of the above use cases or you can define any custom logic to safely approve or reject deployments from pre-production to production environments.
+For general information about deployment protection rules, see [AUTOTITLE](/actions/concepts/use-cases/deploying-with-github-actions#using-custom-deployment-protection-rules).
 
 ## Creating a custom deployment protection rule with {% data variables.product.prodname_github_apps %}