Merge branch 'main' into ske-dep-api

Author: skedwards88

.eslintrc.js

@@ -13,7 +13,7 @@ module.exports = {
     babelOptions: { configFile: './.babelrc' },
     sourceType: 'module',
   },
-  ignorePatterns: ['tmp/*', '!/.*', '/.next/', 'script/bookmarklets/*'],
+  ignorePatterns: ['tmp/*', '!/.*', '/.next/', 'script/bookmarklets/*', 'lib/sigsci.js'],
   rules: {
     'import/no-extraneous-dependencies': ['error', { packageDir: '.' }],
   },

.github/actions-scripts/enterprise-server-issue-templates/release-issue.md

@@ -110,20 +110,20 @@ This file should be automatically updated, but you can also run `script/update-e
 
 ### 🚢 🛳️ 🚢 Shipping the release branch
 
-- [ ] Remove `[DO NOT MERGE]` and other meta information from the PR title 😜.
-- [ ] The `github/docs-internal` repo is frozen, and the `Repo Freeze Check / Prevent merging during deployment freezes (pull_request_target)` test is expected to fail.
-
-  Use admin permissions to ship the release branch with this failure. Make sure that the merge's commit title does not include anything like `[DO NOT MERGE]`, and remove all the branch's commit details from the merge's commit message except for the co-author list.
-- [ ] Do any required smoke tests listed in the opening post in the megabranch PR. You can monitor and check when the production deploy completed by viewing the [`docs-internal` deployments page](https://github.com/github/docs-internal/deployments).
-- [ ] Once smoke tests have passed, you can [unfreeze the repos](https://github.com/github/docs-content/blob/main/docs-content-docs/docs-content-workflows/freezing.md) and post an announcement in Slack.
-- [ ] After unfreezing, the megabranch creator should push the search index LFS objects for the public `github/docs` repo. The LFS objects were already pushed for the internal repo after the `sync-english-index-for-<PLAN@RELEASE>` was added to the megabranch. To push the LFS objects to the public repo:
+- [ ] The megabranch creator should push the search index LFS objects for the public `github/docs` repo. The LFS objects were already pushed for the internal repo after the `sync-english-index-for-<PLAN@RELEASE>` was added to the megabranch. To push the LFS objects to the public repo:
   1. First navigate to the [sync search indices workflow](https://github.com/github/docs-internal/actions/workflows/sync-search-indices.yml). 
   2. Then, to run the workflow with parameters, click on `Run workflow` button. 
   3. A modal will pop up where you will set the following inputs:
-     - Branch: The new version megabranch you're working on
+     - Branch: The new `ghes-<RELEASE>-megabranch` version megabranch you're working on
      - Version: `enterprise-server@<RELEASE>`
      - Language: `en`
   4. Run the job. The workflow job may fail on the first run—so retry the failed job if needed.
+- [ ] Remove `[DO NOT MERGE]` and other meta information from the PR title 😜.
+- [ ] The `github/docs-internal` repo is frozen, and the `Repo Freeze Check / Prevent merging during deployment freezes (pull_request_target)` test is expected to fail.
+
+  Use admin permissions to ship the release branch with this failure. Make sure that the merge's commit title does not include anything like `[DO NOT MERGE]`, and remove all the branch's commit details from the merge's commit message except for the co-author list.
+- [ ] Do any required smoke tests listed in the opening post in the megabranch PR. You can monitor and check when the production deploy completed by viewing the [`docs-internal` deployments page](https://github.com/github/docs-internal/deployments).
+- [ ] Once smoke tests have passed, you can [unfreeze the repos](https://github.com/github/docs-content/blob/main/docs-content-docs/docs-content-workflows/freezing.md) and post an announcement in Slack.
 - [ ] After unfreezing, alert the Ecosystem-API team in #ecosystem-api the docs freeze is finished/thawed and the release has shipped. 
   - [ ] You (or they) can now remove your blocking review on the auto-generated "Update OpenAPI Descriptions" PR in public REST API description (the `rest-api-descriptions` repo). (although it's likely newer PRs have been created since yours with the blocking review, in which case the Ecosystem-API team will close your PR and perform the next step on the most recent PR).
   - [ ] The Ecosystem-API team will merge the latest auto-generated "Update OpenAPI Descriptions" PR (which will contain the OpenAPI schema config that changed `published` to `true` for the release).

assets/images/help/repository/secret-scanning-dry-run-custom-pattern-select-repo.png

@@ -12,7 +12,7 @@
     padding: 8px 8px 16px;
     white-space: pre;
     @include breakpoint(lg) {
-      max-width: 30vw;
+      max-width: 40vw;
     }
   }
 }

components/rest/RestCodeSamples.module.scss

@@ -36,6 +36,10 @@ const responseSelectOptions = [
   { key: 'schema', text: 'Response schema' },
 ]
 
+function getLanguageHighlight(selectedLanguage: string) {
+  return selectedLanguage === JSKEY ? 'javascript' : 'curl'
+}
+
 export function RestCodeSamples({ operation, slug }: Props) {
   const { t } = useTranslation('products')
 
@@ -144,7 +148,7 @@ export function RestCodeSamples({ operation, slug }: Props) {
     const reqElem = responseCodeExample.current
     const scrollElem = scrollRef.current
 
-    // Reset scroll position to the top when switching bteween example response and
+    // Reset scroll position to the top when switching between example response and
     // response schema
     if (scrollElem) {
       scrollElem.scrollTop = 0
@@ -255,8 +259,12 @@ export function RestCodeSamples({ operation, slug }: Props) {
 
         {/* Example requests */}
         <div
-          className={cx(styles.codeBlock, styles.requestCodeBlock, 'border-top rounded-0 my-0')}
-          data-highlight={selectedLanguage === JSKEY ? 'javascript' : 'curl'}
+          className={cx(
+            styles.codeBlock,
+            styles.requestCodeBlock,
+            `border-top rounded-1 my-0 ${getLanguageHighlight(selectedLanguage)}`
+          )}
+          data-highlight={getLanguageHighlight(selectedLanguage)}
         >
           <code ref={requestCodeExample}>{displayedExample[selectedLanguage]}</code>
         </div>
@@ -306,7 +314,7 @@ export function RestCodeSamples({ operation, slug }: Props) {
               className={cx(
                 styles.codeBlock,
                 styles.responseCodeBlock,
-                'border-top rounded-0 my-0'
+                'border-top rounded-1 my-0'
               )}
               data-highlight={'json'}
               style={{ maxHeight: responseMaxHeight }}

components/rest/RestCodeSamples.tsx

@@ -2,6 +2,7 @@
   [class~="highlight"] pre,
   pre {
     margin-top: 0.5rem;
+    border: 1px var(--color-border-default) solid;
   }
 
   [class~="height-constrained-code-block"] pre {

components/ui/MarkdownContent/stylesheets/code.scss

@@ -80,6 +80,20 @@ Maximum concurrency was measured using multiple repositories, job duration of ap
 
 {%- endif %}
 
+{%- ifversion ghes = 3.5 %}
+
+{% data reusables.actions.hardware-requirements-3.5 %}
+
+{% data variables.product.company_short %} measured maximum concurrency using multiple repositories, job duration of approximately 10 minutes, and 10 MB artifact uploads. You may experience different performance depending on the overall levels of activity on your instance.
+
+{% note %}
+
+**Note:** Beginning with {% data variables.product.prodname_ghe_server %} 3.5, {% data variables.product.company_short %}'s internal testing uses 3rd generation CPUs to better reflect a typical customer configuration. This change in CPU represents a small portion of the changes to performance targets in this version of {% data variables.product.prodname_ghe_server %}.
+
+{% endnote %}
+
+{%- endif %}
+
 If you plan to enable {% data variables.product.prodname_actions %} for the users of an existing instance, review the levels of activity for users and automations on the instance and ensure that you have provisioned adequate CPU and memory for your users. For more information about monitoring the capacity and performance of {% data variables.product.prodname_ghe_server %}, see "[Monitoring your appliance](/admin/enterprise-management/monitoring-your-appliance)."
 
 For more information about minimum hardware requirements for {% data variables.product.product_location %}, see the hardware considerations for your instance's platform.

content/admin/github-actions/getting-started-with-github-actions-for-your-enterprise/getting-started-with-github-actions-for-github-enterprise-server.md

@@ -84,7 +84,7 @@ For repositories where {% data variables.product.prodname_dependabot_security_up
 
 You can see all of the alerts that affect a particular project{% ifversion fpt or ghec %} on the repository's Security tab or{% endif %} in the repository's dependency graph. For more information, see "[Viewing {% data variables.product.prodname_dependabot_alerts %} for vulnerable dependencies](/github/managing-security-vulnerabilities/viewing-and-updating-vulnerable-dependencies-in-your-repository)."
 
-By default, we notify people with admin permissions in the affected repositories about new {% data variables.product.prodname_dependabot_alerts %}. {% ifversion fpt or ghec %}{% data variables.product.product_name %} never publicly discloses identified vulnerabilities for any repository. You can also make {% data variables.product.prodname_dependabot_alerts %} visible to additional people or teams working repositories that you own or have admin permissions for. For more information, see "[Managing security and analysis settings for your repository](/github/administering-a-repository/managing-security-and-analysis-settings-for-your-repository#granting-access-to-security-alerts)."
+By default, we notify people with admin permissions in the affected repositories about new {% data variables.product.prodname_dependabot_alerts %}. {% ifversion fpt or ghec %}{% data variables.product.product_name %} never publicly discloses identified vulnerabilities for any repository. You can also make {% data variables.product.prodname_dependabot_alerts %} visible to additional people or teams working with repositories that you own or have admin permissions for. For more information, see "[Managing security and analysis settings for your repository](/github/administering-a-repository/managing-security-and-analysis-settings-for-your-repository#granting-access-to-security-alerts)."
 {% endif %}
 
 {% data reusables.notifications.vulnerable-dependency-notification-enable %}

content/code-security/dependabot/dependabot-alerts/about-dependabot-alerts.md

@@ -30,7 +30,7 @@ shortTitle: Dependabot version updates
 
 {% data variables.product.prodname_dependabot %} takes the effort out of maintaining your dependencies. You can use it to ensure that your repository automatically keeps up with the latest releases of the packages and applications it depends on.
 
-You enable {% data variables.product.prodname_dependabot_version_updates %} by checking a configuration file into your repository. The configuration file specifies the location of the manifest, or of other package definition files, stored in your repository. {% data variables.product.prodname_dependabot %} uses this information to check for outdated packages and applications. {% data variables.product.prodname_dependabot %} determines if there is a new version of a dependency by looking at the semantic versioning ([semver](https://semver.org/)) of the dependency to decide whether it should update to that version. For certain package managers, {% data variables.product.prodname_dependabot_version_updates %} also supports vendoring. Vendored (or cached) dependencies are dependencies that are checked in to a specific directory in a repository rather than referenced in a manifest. Vendored dependencies are available at build time even if package servers are unavailable. {% data variables.product.prodname_dependabot_version_updates %} can be configured to check vendored dependencies for new versions and update them if necessary. 
+You enable {% data variables.product.prodname_dependabot_version_updates %} by checking a _dependabot.yml_configuration file into your repository. The configuration file specifies the location of the manifest, or of other package definition files, stored in your repository. {% data variables.product.prodname_dependabot %} uses this information to check for outdated packages and applications. {% data variables.product.prodname_dependabot %} determines if there is a new version of a dependency by looking at the semantic versioning ([semver](https://semver.org/)) of the dependency to decide whether it should update to that version. For certain package managers, {% data variables.product.prodname_dependabot_version_updates %} also supports vendoring. Vendored (or cached) dependencies are dependencies that are checked in to a specific directory in a repository rather than referenced in a manifest. Vendored dependencies are available at build time even if package servers are unavailable. {% data variables.product.prodname_dependabot_version_updates %} can be configured to check vendored dependencies for new versions and update them if necessary. 
 
 When {% data variables.product.prodname_dependabot %} identifies an outdated dependency, it raises a pull request to update the manifest to the latest version of the dependency. For vendored dependencies, {% data variables.product.prodname_dependabot %} raises a pull request to replace the outdated dependency with the new version directly. You check that your tests pass, review the changelog and release notes included in the pull request summary, and then merge it. For more information, see "[Configuring {% data variables.product.prodname_dependabot %} version updates](/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/enabling-and-disabling-dependabot-version-updates)."
 

content/code-security/dependabot/dependabot-version-updates/about-dependabot-version-updates.md

@@ -321,7 +321,7 @@ For more information about the `@dependabot ignore` commands, see "[Managing pul
 
 You can use the `ignore` option to customize which dependencies are updated. The `ignore` option supports the following options.
 
-- `dependency-name`—use to ignore updates for dependencies with matching names, optionally using `*` to match zero or more characters. For Java dependencies, the format of the `dependency-name` attribute is: `groupId:artifactId` (for example: `org.kohsuke:github-api`).
+- `dependency-name`—use to ignore updates for dependencies with matching names, optionally using `*` to match zero or more characters. For Java dependencies, the format of the `dependency-name` attribute is: `groupId:artifactId` (for example: `org.kohsuke:github-api`). {% if dependabot-grouped-dependencies %} To prevent {% data variables.product.prodname_dependabot %} from automatically updating TypeScript type definitions from DefinitelyTyped, use `@types/*`.{% endif %}
 - `versions`—use to ignore specific versions or ranges of versions. If you want to define a range, use the standard pattern for the package manager (for example: `^1.0.0` for npm, or `~> 2.0` for Bundler).
 - `update-types`—use to ignore types of updates, such as semver `major`, `minor`, or `patch` updates on version updates (for example: `version-update:semver-patch` will ignore patch updates). You can combine this with `dependency-name: "*"` to ignore particular `update-types` for all dependencies. Currently, `version-update:semver-major`, `version-update:semver-minor`, and `version-update:semver-patch` are the only supported options. Security updates are unaffected by this setting.