Repo sync

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

@@ -1,6 +1,6 @@
 name: Check for Spammy Issues
 
-# **What it does**: This action closes low value pull requests in the open-source repository.
+# **What it does**: This action closes low value issues in the open-source repository.
 # **Why we have it**: We get lots of spam in the open-source repository.
 # **Who does it impact**: Open-source contributors.
 

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

@@ -0,0 +1,54 @@
+name: Check for Spammy PRs
+
+# **What it does**: This action closes low value pull requests in the open-source repository.
+# **Why we have it**: We get lots of spam in the open-source repository.
+# **Who does it impact**: Open-source contributors.
+
+on:
+  pull_request_target:
+    types: [opened]
+
+permissions:
+  contents: read
+  pull-requests: write
+
+jobs:
+  spammy-pr-check:
+    name: Label PRs that only delete files or touch a large number of files
+    if: github.repository == 'github/docs' && github.event_name == 'pull_request_target'
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3
+        with:
+          github-token: ${{ secrets.DOCS_BOT_PAT_BASE }}
+          script: |
+            const owner = 'github'
+            const repo = 'docs'
+            const pull_number = context.payload.pull_request.number
+
+            const { data: files } = await github.rest.pulls.listFiles({
+              owner: owner,
+              repo: repo,
+              pull_number: pull_number,
+            });
+
+            const onlyDeletes = files.length > 0 && files.every(f => f.status === 'removed')
+            const touchesTooMany = files.length > 10
+
+            // Close the PR and add the invalid label
+            if (onlyDeletes || touchesTooMany) {
+              await github.rest.issues.update({
+                owner: owner,
+                repo: repo,
+                issue_number: pull_number,
+                labels: ['invalid'],
+              });
+
+              // Comment on the PR
+              await github.rest.issues.createComment({
+                owner: owner,
+                repo: repo,
+                issue_number: pull_number,
+                body: `This pull request may have been opened accidentally. I'm going to close it now, but feel free to check out our [contribution guidelines](https://docs.github.com/en/contributing), or raise a new issue.`
+              });
+            }

.github/workflows/link-check-internal.yml

@@ -47,9 +47,12 @@ jobs:
             # Manual run: use the provided version and language
             echo "matrix={\"include\":[{\"version\":\"${INPUT_VERSION}\",\"language\":\"${INPUT_LANGUAGE}\"}]}" >> $GITHUB_OUTPUT
           else
-            # Scheduled run: English free-pro-team + English latest enterprise-server
-            LATEST_GHES=$(npx tsx -e "import { latest } from './src/versions/lib/enterprise-server-releases'; console.log(latest)")
-            echo "matrix={\"include\":[{\"version\":\"free-pro-team@latest\",\"language\":\"en\"},{\"version\":\"enterprise-server@${LATEST_GHES}\",\"language\":\"en\"}]}" >> $GITHUB_OUTPUT
+            # Scheduled run: every published version, in English. A link can be broken in
+            # one version and fine in another, so checking two of eight left most of the
+            # site unchecked. The report job merges the results, so this does not multiply
+            # the size of the issue.
+            MATRIX=$(npx tsx -e "import { allVersions } from './src/versions/lib/all-versions'; console.log(JSON.stringify({ include: Object.keys(allVersions).map((version) => ({ version, language: 'en' })) }))")
+            echo "matrix=${MATRIX}" >> $GITHUB_OUTPUT
           fi
         env:
           EVENT_NAME: ${{ github.event_name }}
@@ -245,6 +248,17 @@ jobs:
             echo "No broken link reports generated - all links valid!"
           fi
 
+      - name: Upload the combined report
+        if: steps.combine.outputs.has_reports == 'true'
+        uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
+        with:
+          # The issue body caps every long section, and the notes there point at
+          # "the report attached to the workflow run". Upload it so that is true.
+          name: combined-link-report
+          path: combined-report.md
+          retention-days: 5
+          if-no-files-found: error
+
       - name: Create or update the rolling report issue
         if: |
           steps.combine.outputs.has_reports == 'true'
@@ -268,7 +282,15 @@ jobs:
             let body = fs.readFileSync('combined-report.md', 'utf8')
             if (body.length > MAX_BODY_SIZE) {
               const notice = `\n\n---\n\n*Report truncated. Download the full report from the [workflow run artifacts](${runUrl}).*`
-              body = body.slice(0, MAX_BODY_SIZE - notice.length) + notice
+              let cut = body.slice(0, MAX_BODY_SIZE - notice.length)
+              // Cut at a line boundary so the last thing a reader sees is not half
+              // a table row, and close any `<details>` the cut left open, since an
+              // unclosed one swallows everything after it.
+              cut = cut.slice(0, cut.lastIndexOf('\n'))
+              const opened = (cut.match(/<details>/g) || []).length
+              const closed = (cut.match(/<\/details>/g) || []).length
+              cut += '\n</details>'.repeat(Math.max(0, opened - closed))
+              body = cut + notice
               core.warning(`Report exceeded ${MAX_BODY_SIZE} characters, so it was truncated.`)
             }
 

content/code-security/concepts/code-quality/code-quality.md

@@ -20,7 +20,7 @@ category:
 
 {% data variables.product.prodname_code_quality %} analyzes your code for quality and coverage issues and delivers {% data variables.product.prodname_copilot_short %}-powered fixes you can apply in one click. It runs in two places:
 
-* **On pull requests**, {% data variables.product.prodname_code_quality_short %} uses deterministic {% data variables.product.prodname_codeql %} rules to detect known anti-patterns and posts findings as inline comments before code is merged. If you upload a Cobertura XML coverage report, coverage metrics show whether a change maintains or reduces coverage. You can enforce quality and coverage thresholds with rulesets to block pull requests that don't meet your criteria, so new quality debt doesn't accumulate.
+* **On pull requests**, {% data variables.product.prodname_code_quality_short %} uses deterministic {% data variables.product.prodname_codeql %} rules to detect known anti-patterns and posts findings as inline comments before code is merged. If you upload a Cobertura XML coverage report, line coverage metrics show whether a change maintains or reduces coverage. You can enforce quality and coverage thresholds with rulesets to block pull requests that don't meet your criteria, so new quality debt doesn't accumulate.
 * **On the default branch**, rules-based scans identify existing quality debt across your codebase, with autofixes you can apply directly or assign to {% data variables.copilot.copilot_cloud_agent %} to resolve on your behalf. AI-powered analysis also runs on recently changed files, flagging issues that fall outside existing rule sets, including languages not yet covered by {% data variables.product.prodname_codeql %} queries.
 
 > [!NOTE]
@@ -32,14 +32,14 @@ Here's what {% data variables.product.prodname_code_quality %} looks like in pra
 
 For developers and teams:
 
-* **A developer opens a pull request** that introduces a reliability or maintainability issue. {% data variables.product.prodname_code_quality_short %} posts a comment explaining the issue and offers a one-click fix before the code is merged. The developer also sees a report of coverage metrics, and can tell at a glance whether the pull request improves or reduces coverage compared to the default branch.
+* **A developer opens a pull request** that introduces a reliability or maintainability issue. {% data variables.product.prodname_code_quality_short %} posts a comment explaining the issue and offers a one-click fix before the code is merged. The developer also sees a report of line coverage metrics, and can tell at a glance whether the pull request improves or reduces coverage compared to the default branch.
 * **A team inherits a large codebase** with years of accumulated quality debt. {% data variables.product.prodname_code_quality_short %} scans the default branch, surfaces findings with autofixes on a dashboard, and the team assigns remediation work to {% data variables.copilot.copilot_cloud_agent %} to open fix pull requests automatically.
 * **A team adopts AI coding assistants** and needs assurance that generated code meets the same bar as hand-written code. AI-powered analysis catches issues in recently changed files that rule-based queries weren't written for, while {% data variables.product.prodname_codeql %} rules cover well-defined anti-patterns.
 
 For administrators and leads:
 
 * **An engineering lead sets coverage and quality thresholds** using rulesets. Pull requests that don't meet the criteria are blocked from merging, so no new quality or coverage debt accumulates.
-* **An administrator needs visibility across repositories** for audits or compliance reporting. {% data variables.product.prodname_code_quality_short %} reports through the security overview alongside security tools, so they can see quality posture across the organization at a glance, identify which repositories need attention, and track improvement metrics using standard {% data variables.product.github %} audit controls and policies.
+* **An administrator needs visibility across repositories** for audits or compliance reporting. {% data variables.product.prodname_code_quality_short %} reports through the security overview alongside security tools, so they can see current quality posture across the organization, review how open findings have changed over time, and identify which repositories need attention. See [AUTOTITLE](/code-security/how-tos/maintain-quality-code/explore-code-quality).
 
 ## Availability and billing
 

content/code-security/how-tos/maintain-quality-code/explore-code-quality.md

@@ -22,33 +22,106 @@ redirect_from:
 
 ## Viewing code quality insights for your organization
 
+The organization-level dashboard has two tabs:
+
+* The **Health** tab shows a snapshot of your organization's current code health.
+* The **Trends** tab shows how open findings have changed over a selected period of time, so you can track progress and identify repositories that need attention.
+
 1. On {% data variables.product.prodname_dotcom %}, navigate to the main page of your organization. For example, from [https://github.com/settings/organizations](https://github.com/settings/organizations?ref_product=github&ref_type=engagement&ref_style=text&utm_campaign=code-quality-ga-july-2026&utm_medium=docs&utm_source=docs-explore-cq-org-settings).
 {% data reusables.organizations.security-overview %}
-1. In the "Insights" section of the sidebar, click {% octicon "code-square" aria-hidden="true" aria-label="code-square" %} **Code quality**.
+1. In the "Insights" section of the sidebar, click **{% data variables.code-quality.code_quality_ui_settings %}**.
 
 > [!NOTE]
 > What you see on the dashboard depends on your access:
+>
 > * Organization owners see data for **every** repository that has {% data variables.product.prodname_code_quality_short %} enabled.
 > * All other organization members see data only for repositories where they can view {% data variables.product.prodname_code_quality_short %} findings (the repository-level pages), up to a maximum of 3,000 repositories.
 
-## Interpreting the score distribution chart
+## Filtering dashboard data
+
+A filter bar at the top of the dashboard applies to both the **Health** and **Trends** tabs. You can filter by:
+
+* Reliability score
+* Maintainability score
+* {% data variables.code-quality.all_findings %}
+* {% data variables.code-quality.recent_suggestions %}
+* Topic
+* Team
+* Visibility
+* Any custom properties defined for your organization
+
+You can also sort the dashboard data using the **Sort** control in the same filter bar.
+
+## Viewing current code health
+
+The **Health** tab shows a snapshot of your organization's code health right now.
+
+### Interpreting the score distribution chart
 
 The score distribution chart provides a visual overview of the code health of your organization. Each bubble represents a collection of repositories with the same maintainability and reliability scores.
+
 * The **position** of each bubble demonstrates the overall health of those repositories. Higher bubbles represent higher maintainability scores, while bubbles further to the right represent higher reliability scores.
 * The **color and border pattern** of a bubble indicate the severity of the lower score for those repositories. For example, a bubble with a "Poor" score in either category will always be red with a dashed border.
 * The **size** of each bubble represents the number of repositories with that particular score combination.
 
 To view the maintainability score, reliability score, and number of repositories represented by a particular bubble, hover over the bubble.
 
-## Exploring the repository table
+### Exploring the repository table
 
 Below the bubble chart, there is a table that lists all repositories in your organization. Here, you can view code quality findings, along with more detailed information about those findings.
 
 You can sort the repository table in ascending or descending order for any column by clicking the column header.
 
-## Investigating low-scoring repositories
+### Investigating low-scoring repositories
 
 1. To filter the dashboard data for the lowest-performing repositories, on the score distribution chart, click the bubble with the lowest combined scores.
 1. Scroll down to the repository table. By default, the table is sorted from most to least recent repository scan, helping you prioritize current quality issues.
-1. Optionally, to prioritize repositories with the highest number of {% data variables.product.prodname_codeql %} findings, click **Standard Findings** twice.
+1. Optionally, to prioritize repositories with the highest number of {% data variables.product.prodname_codeql %} findings, click **{% data variables.code-quality.all_findings %}** twice.
 1. To view the repository-level dashboard for a specific repository, click the repository's name.
+
+## Tracking quality trends over time
+
+The **Trends** tab shows how open findings across repositories that you have access to and that match the current filters have changed over time, so you can tell whether your code quality work is having an effect and where to focus attention next.
+
+1. On the organization-level dashboard, click the **Trends** tab.
+1. Use the **Period** dropdown to select a time range: the last 7, 14, or 30 days.
+1. Review the "Open findings over time" graph, which shows the total number of open findings across applicable repositories for the selected period.
+1. Optionally, use the buttons above the graph to group the data by **Health score** or **Severity**.
+1. Hover over a point on the graph to see the open finding count for that day.
+
+### Understanding the trends data
+
+Keep the following in mind when you interpret the graph:
+
+* The graph is based on daily snapshots of open findings. If no analysis ran on a given day, there may be no data point for that day.
+* Historical data is only available from when {% data variables.product.prodname_code_quality_short %} started taking snapshots, so the available time range may initially be limited.
+* The graph tracks the total count of open findings, not individual findings being opened or fixed. A change in the count doesn't necessarily mean developers fixed or introduced problems.
+* Enabling {% data variables.product.prodname_code_quality_short %} on additional repositories can increase the finding count shown in the graph. An increase after enabling new repositories doesn't necessarily mean code quality is declining.
+* The graph tracks the total count of open findings for the repositories you are currently filtering on. The total count includes:
+
+  * New findings that are introduced by code changes or when code quality analysis is enabled on new repositories
+  * Findings that are fixed in the code or dismissed by users
+
+## Identifying repositories that need attention
+
+Below the trends graph, two tables help you identify which repositories need attention over the selected time period:
+
+* **Most improved repositories** lists repositories with the largest decrease in open findings over the selected time period.
+* **Repositories needing improvement** lists repositories with the largest increase in open findings over the selected time period.
+
+Both tables include the following columns:
+
+* **Repository**: The name of the repository.
+* **Total open**: The number of open findings for the repository at the end of the selected time period.
+* **Net change**: How the open finding count for the repository has changed over the selected time period.
+* **Dismissed**: How many findings were dismissed for the repository over the selected time period.
+
+The number of findings for a repository is affected by findings being fixed and dismissed. You can use the repository-level dashboard to confirm what changed.
+
+To investigate a repository, click its name to open its repository-level {% data variables.product.prodname_code_quality_short %} dashboard, where you can review individual findings and take remediation action.
+
+## Next steps
+
+To understand the code health information available on the repository-level dashboard, see [AUTOTITLE](/code-security/how-tos/maintain-quality-code/interpret-results).
+
+If you're planning to enable {% data variables.product.prodname_code_quality_short %} across many repositories, see [AUTOTITLE](/code-security/how-tos/maintain-quality-code/roll-out-at-scale).

content/code-security/how-tos/maintain-quality-code/restrict-code-coverage.md

@@ -19,6 +19,9 @@ category:
 * {% data variables.product.prodname_code_quality %} is enabled on the repository.
 * Code coverage data is uploaded to {% data variables.product.github %} for the pull request branch. See [AUTOTITLE](/code-security/how-tos/maintain-quality-code/set-up-code-coverage).
 
+> [!NOTE]
+> Coverage thresholds are evaluated against **line coverage**. See [AUTOTITLE](/code-security/reference/code-quality/code-coverage).
+
 ## Creating a coverage threshold rule
 
 {% data reusables.repositories.navigate-to-repo %}
@@ -28,8 +31,8 @@ category:
 1. Under "Branch rules", select **Restrict code coverage**.
 1. Expand **Additional settings** to configure thresholds. A value of 0 means that the threshold is disabled.
 
-   * **Minimum coverage percentage**: enter a value to block pull requests where aggregated coverage falls below this percentage.
-   * **Maximum coverage drop**: enter a value to block pull requests where coverage drops by more than this many percentage points relative to the default branch.
+   * **Minimum line coverage percentage**: enter a value to block pull requests where aggregated line coverage falls below this percentage.
+   * **Maximum line coverage drop**: enter a value to block pull requests where line coverage drops by more than this many percentage points relative to the default branch.
 
 1. Click **Create** or **Save changes**.
 

content/code-security/how-tos/maintain-quality-code/set-pr-thresholds.md

@@ -21,7 +21,7 @@ You can block pull requests that don't meet your code quality standards by addin
 You can set thresholds for:
 
 * **{% data variables.product.prodname_codeql %} findings**, by the lowest severity of results you require to be resolved.
-* **Code coverage**, by the minimum percentage of code that must be covered by tests.
+* **Code coverage**, by the minimum percentage of lines that must be covered by tests.
 
 You can enforce these thresholds at the **repository** level, or at the **organization** level to apply the same standard across many repositories at once. Choose the organization level when you want a consistent quality bar across teams, and the repository level when a single project needs its own standard. {% data variables.product.prodname_code_quality_short %} {% data variables.code-quality.recent_suggestions %} cannot be set as a threshold.