diff --git a/content/actions/concepts/workflows-and-actions/reusing-workflow-configurations.md b/content/actions/concepts/workflows-and-actions/reusing-workflow-configurations.md index 99827ecf3b68..3c7f565071c7 100644 --- a/content/actions/concepts/workflows-and-actions/reusing-workflow-configurations.md +++ b/content/actions/concepts/workflows-and-actions/reusing-workflow-configurations.md @@ -56,7 +56,7 @@ Let's compare some aspects of each solution: | Called directly within a job, not from a step | Run as a step within a job | | Can contain multiple jobs | Does not contain jobs | | Each step is logged in real-time | Logged as one step even if it contains multiple steps | -| Can connect a maximum of {% ifversion fpt or ghec %}ten {% else %}four {% endif %}levels of workflows | Can be nested to have up to 10 composite actions in one workflow | +| Can connect a maximum of ten levels of workflows | Can be nested to have up to 10 composite actions in one workflow | | Can use secrets | Cannot use secrets | | Cannot be published to the [marketplace](https://github.com/marketplace?type=actions) | Can be published to the [marketplace](https://github.com/marketplace?type=actions) | diff --git a/content/actions/how-tos/reuse-automations/reuse-workflows.md b/content/actions/how-tos/reuse-automations/reuse-workflows.md index 5bee09030726..ce61c0e22d72 100644 --- a/content/actions/how-tos/reuse-automations/reuse-workflows.md +++ b/content/actions/how-tos/reuse-automations/reuse-workflows.md @@ -181,9 +181,7 @@ jobs: ## Nesting reusable workflows -You can connect a maximum of {% ifversion fpt or ghec %}ten levels of workflows - that is, the top-level caller workflow and up to nine levels of reusable workflows. For example: _caller-workflow.yml_ → _called-workflow-1.yml_ → _called-workflow-2.yml_ → _called-workflow-3.yml_ → ... → _called-workflow-9.yml_.{% else %}four levels of workflows - that is, the top-level caller workflow and up to three levels of reusable workflows. For example: _caller-workflow.yml_ → _called-workflow-1.yml_ → _called-workflow-2.yml_ → _called-workflow-3.yml_.{% endif %} - -Loops in the workflow tree are not permitted. +You can connect a maximum of ten levels of workflows - that is, the top-level caller workflow and up to nine levels of reusable workflows. For example: _caller-workflow.yml_ → _called-workflow-1.yml_ → _called-workflow-2.yml_ → _called-workflow-3.yml_ → ... → _called-workflow-9.yml_. Loops in the workflow tree are not permitted. > [!NOTE] Nested reusable workflows require all workflows in the chain to be accessible to the caller, and permissions can only be maintained or reduced—not elevated—throughout the chain. For more information, see [AUTOTITLE](/actions/reference/reusable-workflows-reference#access-and-permissions-for-nested-workflows). diff --git a/content/actions/reference/workflows-and-actions/reusing-workflow-configurations.md b/content/actions/reference/workflows-and-actions/reusing-workflow-configurations.md index bf9d93492f63..26be36847dd1 100644 --- a/content/actions/reference/workflows-and-actions/reusing-workflow-configurations.md +++ b/content/actions/reference/workflows-and-actions/reusing-workflow-configurations.md @@ -46,9 +46,8 @@ For {% ifversion ghes or ghec %}internal or {% endif %}private repositories, the ### Limitations of reusable workflows - -* You can connect up to {% ifversion fpt or ghec %}ten {% else %}four {% endif %}levels of workflows. For more information, see [Nesting reusable workflows](/actions/how-tos/sharing-automations/reuse-workflows#nesting-reusable-workflows). -* You can call a maximum of {% ifversion fpt or ghec %}50 {% else %}20 {% endif %}unique reusable workflows from a single workflow file. This limit includes any trees of nested reusable workflows that may be called starting from your top-level caller workflow file. +* You can connect up to ten levels of workflows. For more information, see [Nesting reusable workflows](/actions/how-tos/sharing-automations/reuse-workflows#nesting-reusable-workflows). +* You can call a maximum of 50 unique reusable workflows from a single workflow file. This limit includes any trees of nested reusable workflows that may be called starting from your top-level caller workflow file. For example, _top-level-caller-workflow.yml_ → _called-workflow-1.yml_ → _called-workflow-2.yml_ counts as 2 reusable workflows. diff --git a/content/admin/backing-up-and-restoring-your-instance/backup-service-for-github-enterprise-server/configuring-the-backup-service.md b/content/admin/backing-up-and-restoring-your-instance/backup-service-for-github-enterprise-server/configuring-the-backup-service.md index e3c2e09b6032..1f2026cef1f7 100644 --- a/content/admin/backing-up-and-restoring-your-instance/backup-service-for-github-enterprise-server/configuring-the-backup-service.md +++ b/content/admin/backing-up-and-restoring-your-instance/backup-service-for-github-enterprise-server/configuring-the-backup-service.md @@ -80,9 +80,8 @@ If you're using a dedicated block device as your backup target, you need to init This command: * Formats the device (erases all data). * Prepares it for use by the backup service. - * Sets it to mount automatically at `/data/backup` on boot.{% ifversion ghes > 3.19 %} - * If in a clustered environment, configures the node in `cluster.conf` with the `backup-server` role.{% endif %} - + * Sets it to mount automatically at `/data/backup` on boot. + {% ifversion ghes = 3.17 %} From {% data variables.product.prodname_ghe_server %} 3.17.4 onward, the script is installed in PATH so you can run it directly using: `ghe-storage-init-backup /dev/YOUR_DEVICE_NAME`. {% endif %} @@ -110,9 +109,9 @@ If the device was already initialized using `ghe-storage-init-backup`, you can r ### Configuring backup settings -After the backup target is mounted, the Backup Service page will become available in the {% data variables.enterprise.management_console %}. {% ifversion ghes > 3.19 %} If your instance is part of a clustered environment, the system will automatically detect the node that was initialized with `ghe-storage-init-backup` and treat it as the backup server. {% endif %} +After the backup target is mounted, the Backup Service page will become available in the {% data variables.enterprise.management_console %}. If you're using a block device, this requires completing the initialization or mount steps above. ->[!NOTE] The settings page won’t appear until the backup storage is mounted at `/data/backup` by completing the initialization or mount steps above. +>[!NOTE] The settings page won’t appear until the backup storage is mounted at `/data/backup`. If you're migrating from {% data variables.product.prodname_enterprise_backup_utilities %}, you can transfer your configuration in one of two ways: diff --git a/src/graphql/components/Changelog.tsx b/src/graphql/components/Changelog.tsx index cc1d06777803..9976d8e095ef 100644 --- a/src/graphql/components/Changelog.tsx +++ b/src/graphql/components/Changelog.tsx @@ -1,6 +1,5 @@ import React from 'react' import cx from 'classnames' -import GithubSlugger from 'github-slugger' import { HeadingLink } from '@/frame/components/article/HeadingLink' import { ChangelogItemT } from './types' @@ -11,19 +10,14 @@ type Props = { } export function Changelog({ changelogItems }: Props) { - const slugger = new GithubSlugger() - - const changes = changelogItems.map((item, index) => { + const changes = changelogItems.map((item) => { const heading = `Schema changes for ${item.date}` - const slug = slugger.slug(heading) return ( -
- - {heading} - - {(item.schemaChanges || []).map((change, changeIndex) => ( - +
+ {heading} + {(item.schemaChanges || []).map((change, index) => ( +

{change.title}

    {change.changes.map((changeItem) => ( @@ -32,8 +26,8 @@ export function Changelog({ changelogItems }: Props) {
))} - {(item.previewChanges || []).map((change, changeIndex) => ( - + {(item.previewChanges || []).map((change, index) => ( +

{change.title}

    {change.changes.map((changeItem) => ( @@ -42,8 +36,8 @@ export function Changelog({ changelogItems }: Props) {
))} - {(item.upcomingChanges || []).map((change, changeIndex) => ( - + {(item.upcomingChanges || []).map((change, index) => ( +

{change.title}

{change.changes.map((changeItem) => (
  • diff --git a/src/graphql/tests/server-rendering.ts b/src/graphql/tests/server-rendering.ts index 177bb94f37d3..cc3d8238593d 100644 --- a/src/graphql/tests/server-rendering.ts +++ b/src/graphql/tests/server-rendering.ts @@ -23,26 +23,6 @@ describe('server rendering certain GraphQL pages', () => { expect.assertions(hrefs.length + 1) }) - test('minitoc hrefs on changelog match and verify slugger behavior', async () => { - // Testing the minitoc links match the heading ids but also validating - // slugger behavior see docs-engineering/issues#5792. - // Little funky because we need to make 2 requests to the page to test - // the problem behavior where slugger state accumulates across - // requests, it won't fail the first time around. - await getDOM('/graphql/overview/changelog') - const $ = await getDOM('/graphql/overview/changelog') - const links = $('[data-testid="minitoc"] a[href]') - const hrefs = links.map((i, link) => $(link).attr('href')).get() - const headings = $('#article-contents h2') - const headingIds = headings.map((i, heading) => `#${$(heading).attr('id')}`).get() - - expect(hrefs.length).toBe(headingIds.length) - - for (let i = 0; i < hrefs.length; i++) { - expect(hrefs[i]).toBe(headingIds[i]) - } - }) - const autogeneratedPages = pageList.filter( (page) => page.autogenerated === 'graphql' && page.relativePath.includes('reference'), )