Repo sync

.github/workflows/line-endings.yml

@@ -0,0 +1,45 @@
+name: Line endings
+
+# **What it does**: Fails if any committed file violates the repo's `.gitattributes`
+#   line-ending rules (for example, CRLF in a file declared `eol=lf`).
+# **Why we have it**: `.gitattributes` (`*.md text eol=lf`, `* text=auto`) only
+#   normalizes line endings during a local `git add`/checkout. A server-side
+#   squash-merge can commit CRLF blobs that bypass it. A file with mixed line endings
+#   then shows as permanently "modified" on Linux runners, which breaks PR-creating
+#   sync workflows that use peter-evans/create-pull-request. See
+#   github/docs-engineering#6657 and github/docs-engineering#6656.
+# **Who does it impact**: Docs engineering, open-source engineering contributors.
+
+on:
+  workflow_dispatch:
+  merge_group:
+  pull_request:
+
+permissions:
+  contents: read
+
+# This allows a subsequently queued workflow run to interrupt previous runs
+concurrency:
+  group: '${{ github.workflow }} @ ${{ github.event.pull_request.head.label || github.head_ref || github.ref }}'
+  cancel-in-progress: true
+
+jobs:
+  line-endings:
+    if: github.repository == 'github/docs-internal' || github.repository == 'github/docs'
+    runs-on: ubuntu-latest
+    steps:
+      - name: Check out repo
+        uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
+
+      - name: Check line endings
+        # Re-stage every file through the `.gitattributes` filters and fail if any
+        # committed blob disagrees with them (usually CRLF where LF is required).
+        run: |
+          git add --renormalize .
+          if ! git diff --cached --quiet; then
+            echo "::error::These files violate .gitattributes line-ending rules (usually CRLF that should be LF):"
+            git diff --cached --name-only
+            echo ""
+            echo "Fix locally with: git add --renormalize . && git commit"
+            exit 1
+          fi

.github/workflows/sync-sdk-docs.yml

@@ -24,7 +24,7 @@ on:
     types: [opened, synchronize, reopened]
     paths:
       - '.github/workflows/sync-sdk-docs.yml'
-      - 'src/scripts/sync-sdk-docs/**'
+      - 'src/workflows/sync-sdk-docs/**'
 
 concurrency:
   group: sync-sdk-docs-${{ github.event_name }}
@@ -88,7 +88,7 @@ jobs:
 
       - name: Normalize content
         run: |
-          npx tsx src/scripts/sync-sdk-docs/normalize-sdk-docs.ts \
+          npx tsx src/workflows/sync-sdk-docs/normalize-sdk-docs.ts \
             --content-dir content \
             --sdk-docs-dir "$SDK_DOCS_TARGET"
 
@@ -98,7 +98,7 @@ jobs:
         run: |
           # Puppeteer needs --no-sandbox on GitHub Actions runners
           echo '{ "args": ["--no-sandbox", "--disable-setuid-sandbox"] }' > /tmp/puppeteer-config.json
-          npx tsx src/scripts/sync-sdk-docs/convert-mermaid.ts \
+          npx tsx src/workflows/sync-sdk-docs/convert-mermaid.ts \
             --sdk-docs-dir "$SDK_DOCS_TARGET" \
             --assets-dir "$ASSETS_TARGET" \
             --repo-root . \

config/moda/secrets/production/secrets.yml

@@ -14,6 +14,11 @@ secrets:
     type: salt
     owner: '@github/docs-engineering'
     externally_usable: true
+  DOCS_BOT_APP_CLIENT_ID:
+    kind: latest_at_deployment_start
+    type: github_app
+    owner: '@github/docs-engineering'
+    externally_usable: true
   DOCS_BOT_APP_ID:
     kind: latest_at_deployment_start
     type: github_app

content/actions/how-tos/manage-runners/use-proxy-servers.md

@@ -33,7 +33,7 @@ On Windows machines, the proxy environment variable names are case-insensitive.
 {% data reusables.actions.self-hosted-runner-ports-protocols %}
 
 > [!WARNING]
-> Self-hosted runners do not support using IP addresses in the `no_proxy` environment variable. If your {% data variables.product.prodname_ghe_server %} instance uses an IP address and you configure `no_proxy` to bypass the proxy for that address, the runner will still fail to connect.
+> Self-hosted runners do not support using IP addresses and CIDR ranges in the `no_proxy` environment variable. If your {% data variables.product.prodname_ghe_server %} instance uses an IP address and you configure `no_proxy` to bypass the proxy for that address, the runner will still fail to connect.
 > If your {% data variables.product.prodname_ghe_server %} instance is accessed using an IP address and the connection must bypass the proxy, the runner will fail to connect, even if that IP address is listed in `no_proxy`.
 
 ### Example configurations

content/admin/managing-github-actions-for-your-enterprise/advanced-configuration-and-troubleshooting/migrating-github-actions-external-storage.md

@@ -10,11 +10,11 @@ category:
   - Enable GitHub features for your enterprise
 ---
 
-## About migrating {% data variables.product.prodname_actions %} external storage
-
-You can migrate {% data variables.product.prodname_actions %} external storage to a new bucket, account, or region on the same provider when consolidating cloud accounts, meeting residency requirements, or reorganizing storage tenancy.
-
-The migration works because {% data variables.product.prodname_actions %} identifies stored objects by their key (path) within a bucket or container, not by the bucket or account name. As long as you preserve the internal key layout and update your configuration to point at the new location, existing workflow logs and artifacts remain accessible without interruption.
+## About migrating {% data variables.product.prodname_actions %} external storage
+
+You can migrate {% data variables.product.prodname_actions %} external storage to a new bucket, account, or region on the same provider when consolidating cloud accounts, meeting residency requirements, or reorganizing storage tenancy.
+
+The migration works because {% data variables.product.prodname_actions %} identifies stored objects by their key (path) within a bucket or container, not by the bucket or account name. As long as you preserve the internal key layout and update your configuration to point at the new location, existing workflow logs and artifacts remain accessible without interruption.
 
 ## Considerations
 
@@ -43,12 +43,12 @@ Before you begin, review the following constraints. Each one shapes the migratio
 
 Before performing the migration against production, rehearse the full procedure on a staging instance. Provision a staging {% data variables.product.prodname_ghe_server %} instance from a recent production backup, point it at a throwaway destination that mirrors the intended production destination, and run every step of this article end to end. For more information, see [AUTOTITLE](/admin/installation/setting-up-a-github-enterprise-server-instance/setting-up-a-staging-instance) and [AUTOTITLE](/admin/managing-github-actions-for-your-enterprise/advanced-configuration-and-troubleshooting/using-a-staging-environment).
 
-A staging rehearsal validates that:
-
-* Provider-side permissions, network access, and policies on the destination are correct.
-* The copy tool you have chosen completes successfully against representative data volumes.
-* The expected object count and total size match between source and destination.
-* Existing workflow run logs and artifacts are retrievable through the UI after cutover.
+A staging rehearsal validates that:
+
+* Provider-side permissions, network access, and policies on the destination are correct.
+* The copy tool you have chosen completes successfully against representative data volumes.
+* The expected object count and total size match between source and destination.
+* Existing workflow run logs and artifacts are retrievable through the UI after cutover.
 
 > [!WARNING]
 > Your staging instance must use different storage from your production instance. If you do not change the storage configuration, the staging instance may write into your production storage and cause data loss. For more information, see [AUTOTITLE](/admin/managing-github-actions-for-your-enterprise/advanced-configuration-and-troubleshooting/using-a-staging-environment#configuring-storage).
@@ -135,23 +135,23 @@ Work through the following steps in order. {% data variables.product.prodname_ac
 
 If validation fails or you encounter issues after cutover, roll back by pointing {% data variables.location.product_location %} back at the source storage location. The source storage is your known-good copy. Do not copy data from the destination back into the source as part of rollback, because data written to the destination during a failed cutover may be partial or inconsistent, and writing it back into the source risks corrupting your only good copy.
 
-> [!WARNING]
-> Rolling back will discard any data written or deleted after the cutover. If validation fails, roll back immediately rather than attempting extended troubleshooting. The longer you wait, the more data is at risk.
-
-If validation fails or you encounter issues:
-
-1. Enable maintenance mode immediately.
-1. In the {% data variables.enterprise.management_console %}, restore the original storage configuration values and click **Test storage settings**, then **Save settings**.
-1. Disable maintenance mode and re-run the validation steps with the original storage.
-
-After a successful rollback, investigate the failure and plan a new migration attempt.
+> [!WARNING]
+> Rolling back will discard any data written or deleted after the cutover. If validation fails, roll back immediately rather than attempting extended troubleshooting. The longer you wait, the more data is at risk.
+
+If validation fails or you encounter issues:
+
+1. Enable maintenance mode immediately.
+1. In the {% data variables.enterprise.management_console %}, restore the original storage configuration values and click **Test storage settings**, then **Save settings**.
+1. Disable maintenance mode and re-run the validation steps with the original storage.
+
+After a successful rollback, investigate the failure and plan a new migration attempt.
 
 ## {% data variables.product.prodname_registry %} considerations
 
 You can apply the same migration approach to {% data variables.product.prodname_registry %} external storage, with the following important differences. Read this section in full before migrating storage on an instance that has {% data variables.product.prodname_registry %} enabled.
 
 * **OpenID Connect is not available for {% data variables.product.prodname_registry %}.** {% data variables.product.prodname_registry %} only supports credentials-based authentication for external storage. The authentication-method constraint in this article still applies: keep the authentication method unchanged during migration.
-* **{% data variables.product.prodname_registry %} is more sensitive to timing mismatches.** When packages are published during the migration window, the system creates both new storage objects and database records. To prevent inconsistency, keep maintenance mode enabled continuously from the start of the final delta sync through successful validation of the new configuration.
+* **{% data variables.product.prodname_registry %} is more sensitive to timing mismatches.** When packages are published during the migration window, the system creates both new storage objects and database records. To prevent inconsistency, keep maintenance mode enabled continuously from the start of the final delta sync through successful validation of the new configuration.
 * **Update both configurations together if the same provider serves both products.** If you have configured {% data variables.product.prodname_actions %} and {% data variables.product.prodname_registry %} to use the same provider type and you are migrating both, plan the cutover as a single maintenance window and update both configurations before disabling maintenance mode.
 * **For cross-provider migrations of {% data variables.product.prodname_registry %} storage, contact {% data variables.contact.contact_ent_support %}.** Cross-provider moves are not covered here.
 

content/code-security/concepts/supply-chain-security/index.md

@@ -10,6 +10,7 @@ redirect_from:
   - /code-security/supply-chain-security/understanding-your-software-supply-chain
 children:
   - supply-chain-security
+  - open-source-license-compliance
   - best-practices-for-maintaining-dependencies
   - dependency-graph
   - dependency-graph-data

content/code-security/concepts/supply-chain-security/open-source-license-compliance.md

@@ -0,0 +1,60 @@
+---
+title: About open source license compliance
+shortTitle: Open Source license compliance
+intro: Define and enforce license policy for dependencies in your repositories with open source license compliance.
+product: 'Organizations owned by an enterprise account with {% data variables.product.prodname_GH_code_security %} enabled'
+versions:
+  feature: open-source-license-compliance
+contentType: concepts
+category:
+  - Secure your dependencies
+---
+
+{% data reusables.code-security.open-source-license-compliance-public-preview-note %}
+
+## Overview
+
+Open source license compliance helps you **track dependency licenses** and **enforce policy** for the open source software in your supply chain. You can use license compliance to reduce legal and operational risk, catching nonconforming dependencies **before** changes are merged.
+
+## How license policy works
+
+You can define an enterprise or organization policy that controls which licenses dependencies are allowed to use.
+
+You can specify licenses from either a built-in list or, if a license is not listed, by manually adding a SPDX license identifier.
+
+Your policy is applied at the enterprise, organization, and repository scope. You can also add package or license exceptions when an **Enterprise Open Source License Manager** approves requests.
+
+License evaluation uses dependency data from your repositories, including transitive dependencies detected in the dependency graph.
+
+## How pull request enforcement works
+
+Open source license compliance is enforced through branch rulesets. When a pull request changes package manifests, {% data variables.product.github %} compares dependency changes between the base and pull request branches, evaluates detected licenses against policy, and reports violations.
+
+If there is a ruleset in **Active** mode which uses the "Requires license compliance results before merging" condition, pull requests that introduce noncompliant dependencies are blocked until violations are resolved. An **Evaluate** mode ruleset with that condition will run license checks and annotate the pull request, but not block merges.
+
+Additionally, a [branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule) that requires comment resolution before merging will track annotations from license checks, so even alerts generated by **Evaluate** rulesets will be subject to the protection.
+
+## Where results appear
+
+If a dependency's license isn't in your policy, findings will appear in pull request annotations. The annotations do not automatically generate an exception request, because the developer could decide to modify their code to avoid the noncompliant dependency. If they do want to use the dependency, {% data variables.product.github %} will prompt the developer for more information, then send the closure request to the Enterprise Open Source License Managers, who have permission to modify the policy.
+
+For Enterprise Open Source License Managers, pending exception requests are available in enterprise security views and sent as email notifications.
+
+## Scope and governance model
+
+You can create policy at enterprise scope for a common baseline, then layer repository-specific exceptions where needed.
+
+For large enterprises, a common pattern is:
+
+* Define broad policy centrally
+* Assign the Enterprise Open Source License Manager role to policy reviewers
+* Use a repository custom property to classify repositories as inactive, evaluate, or active
+* Use rulesets that target the custom property values to control enforcement mode by repository
+
+Developers with write access can view the effective policy and exceptions for a repository from the repository's license policy settings page.
+
+## Next steps
+
+To get started, see [AUTOTITLE](/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-license-policies).
+
+For more information about rulesets, see [AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets).

content/code-security/how-tos/secure-your-supply-chain/index.md

@@ -17,4 +17,3 @@ children:
   - secure-your-dependencies
   - manage-your-dependency-security
   - establish-provenance-and-integrity
----