diff --git a/.github/workflows/link-check-internal.yml b/.github/workflows/link-check-internal.yml index eec731ee3965..595734531cde 100644 --- a/.github/workflows/link-check-internal.yml +++ b/.github/workflows/link-check-internal.yml @@ -14,6 +14,16 @@ on: type: string required: true default: 'en' + create_copilot_issue: + description: 'Create a Copilot-assigned issue with the top 5 redirects to fix' + type: boolean + required: false + default: false + create_report: + description: 'Create the combined broken links report issue in docs-content' + type: boolean + required: false + default: true permissions: contents: read @@ -101,6 +111,60 @@ jobs: retention-days: 5 if-no-files-found: ignore + - name: Create Copilot redirect issue + if: inputs.create_copilot_issue + uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd + with: + github-token: ${{ secrets.DOCS_BOT_PAT_BASE }} + script: | + const fs = require('fs') + const reportFile = 'artifacts/link-report-${{ matrix.version }}-${{ matrix.language }}.json' + + if (!fs.existsSync(reportFile)) { + core.info('No JSON report found — all links valid, skipping Copilot issue.') + return + } + + const report = JSON.parse(fs.readFileSync(reportFile, 'utf8')) + const redirectGroups = report.groups.filter(g => g.isWarning).slice(0, 5) + + if (redirectGroups.length === 0) { + core.info('No redirect groups found, skipping Copilot issue.') + return + } + + const tableRows = redirectGroups.map(g => { + const occ = g.occurrences[0] + const redirectTarget = occ?.redirectTarget ?? 'unknown' + const file = occ?.file ?? 'unknown' + const lines = (occ?.lines ?? []).join(', ') + return `| \`${g.target}\` | \`${redirectTarget}\` | \`${file}\` | ${lines} |` + }).join('\n') + + const body = [ + '@copilot Please fix the redirected internal links listed in the table below.', + 'All changes should be made within the `github/docs-internal` repository.', + 'For each entry, open the source file and replace the **Current Link** with the **Update To** path.', + 'When all changes are made, open a pull request in `github/docs-internal` with the fixes.', + '', + '## Redirects to fix', + '', + '| Current Link | Update To | File | Line(s) |', + '|---|---|---|---|', + tableRows, + ].join('\n') + + const issue = await github.rest.issues.create({ + owner: 'github', + repo: 'docs-content', + title: '[Copilot Task] Fix top redirect links: ${{ matrix.version }}/${{ matrix.language }}', + body, + labels: ['broken link report'], + assignees: ['copilot'], + }) + + core.info(`Created Copilot redirect issue: ${issue.data.html_url}`) + - uses: ./.github/actions/slack-alert if: ${{ failure() && github.event_name != 'workflow_dispatch' }} with: @@ -159,7 +223,7 @@ jobs: fi - name: Create issue if broken links found - if: steps.combine.outputs.has_reports == 'true' + if: steps.combine.outputs.has_reports == 'true' && (github.event_name != 'workflow_dispatch' || inputs.create_report != false) uses: peter-evans/create-issue-from-file@fca9117c27cdc29c6c4db3b86c48e4115a786710 # v5 with: token: ${{ secrets.DOCS_BOT_PAT_BASE }} diff --git a/content/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities.md b/content/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities.md index 043e5610f307..7e72e0d17816 100644 --- a/content/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities.md +++ b/content/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities.md @@ -1287,6 +1287,12 @@ GHE_LICENSE_FILE=/path/license ghe-license import # License synchronized. ``` +## Migrations + +### elm + +`elm` is the command-line tool for {% data variables.product.prodname_elm %}, a tool for live migrations to {% data variables.enterprise.data_residency_site %}. See [AUTOTITLE](/migrations/elm/elm-cli-reference). + ## Security ### ghe-find-insecure-git-operations diff --git a/content/admin/data-residency/feature-overview-for-github-enterprise-cloud-with-data-residency.md b/content/admin/data-residency/feature-overview-for-github-enterprise-cloud-with-data-residency.md index c36108cd7bb9..2a46e68bb86e 100644 --- a/content/admin/data-residency/feature-overview-for-github-enterprise-cloud-with-data-residency.md +++ b/content/admin/data-residency/feature-overview-for-github-enterprise-cloud-with-data-residency.md @@ -40,7 +40,7 @@ By design, the following features are permanently unavailable on {% data variabl | Feature | Details | More information | | :- | :- | :- | | Features unavailable with {% data variables.product.prodname_emus %} | Because {% data variables.product.prodname_emus %} is the only option for identity management on {% data variables.enterprise.data_residency_site %}, features that are unavailable with {% data variables.product.prodname_emus %} on {% data variables.product.prodname_dotcom_the_website %} are also unavailable on {% data variables.enterprise.data_residency_site %}. Notably, these include gists and public repositories. | [AUTOTITLE](/admin/managing-iam/understanding-iam-for-enterprises/abilities-and-restrictions-of-managed-user-accounts) | -| {% data variables.product.prodname_importer %} (the "Import repository" button on {% data variables.product.prodname_dotcom_the_website %}) | Instead, the **{% data variables.product.prodname_importer_proper_name %}** is available to migrate data. See [AUTOTITLE](/migrations/using-github-enterprise-importer/understanding-github-enterprise-importer/about-github-enterprise-importer). | [AUTOTITLE](/migrations/importing-source-code/using-github-importer/about-github-importer) | +| {% data variables.product.prodname_importer %} (the "Import repository" button on {% data variables.product.prodname_dotcom_the_website %}) | This is distinct from **{% data variables.product.prodname_importer_proper_name %}**, which is one of the tools available to migrate data. See [AUTOTITLE](/admin/data-residency/getting-started-with-data-residency-for-github-enterprise-cloud#5-migrate-data). | [AUTOTITLE](/migrations/importing-source-code/using-github-importer/about-github-importer) | ## Features that work differently diff --git a/content/admin/data-residency/getting-started-with-data-residency-for-github-enterprise-cloud.md b/content/admin/data-residency/getting-started-with-data-residency-for-github-enterprise-cloud.md index 6b2f2f7967af..f3863bd6df35 100644 --- a/content/admin/data-residency/getting-started-with-data-residency-for-github-enterprise-cloud.md +++ b/content/admin/data-residency/getting-started-with-data-residency-for-github-enterprise-cloud.md @@ -116,6 +116,7 @@ To migrate existing data to your new enterprise on {% data variables.enterprise. Optionally, you can migrate data to {% data variables.enterprise.data_residency_site %} during your trial. However, migrated organizations will count towards the limit of three new organizations during the trial. * If you're migrating from {% data variables.product.prodname_dotcom_the_website %}, {% data variables.product.prodname_ghe_server %}, Azure DevOps, or Bitbucket Server, you can migrate source code history and metadata with {% data variables.product.prodname_importer_proper_name %}. See [AUTOTITLE](/migrations/using-github-enterprise-importer/understanding-github-enterprise-importer/about-github-enterprise-importer). +* For migrations from {% data variables.product.prodname_ghe_server %} 3.17 and later, you can use {% data variables.product.prodname_elm %}. This offers less downtime and better support for complex monorepos. See [AUTOTITLE](/migrations/elm/about-live-migrations). * If you're migrating from a different platform, see [AUTOTITLE](/migrations/overview/migration-paths-to-github#migrations-to-ghecom). ### Example script for {% data variables.product.prodname_importer_proper_name %} diff --git a/content/admin/monitoring-and-managing-your-instance/multiple-data-disks/configuring-multiple-data-disks.md b/content/admin/monitoring-and-managing-your-instance/multiple-data-disks/configuring-multiple-data-disks.md index 96222a22dbac..94d9570c8741 100644 --- a/content/admin/monitoring-and-managing-your-instance/multiple-data-disks/configuring-multiple-data-disks.md +++ b/content/admin/monitoring-and-managing-your-instance/multiple-data-disks/configuring-multiple-data-disks.md @@ -3,15 +3,12 @@ title: Configuring multiple data disks product: '{% data variables.product.prodname_ghe_server %}' intro: You can configure additional data disks and use them to host data of different services. versions: - ghes: '>= 3.19' + ghes: '>= 3.17' contentType: concepts category: - Scale your instance --- -> [!NOTE] -> The ability to configure and use multiple data disks is in {% data variables.release-phases.public_preview %} and subject to change. We would love to hear your feedback on the preview. You can share it with your customer success team, or leave a comment in the [community discussion post](https://github.com/orgs/community/discussions/181173). Our preferred option is sharing your feedback with your customer success team. - ## Why introduce more disks to the GHES instance? * Improved resource distribution: diff --git a/content/communities/moderating-comments-and-conversations/managing-disruptive-comments.md b/content/communities/moderating-comments-and-conversations/managing-disruptive-comments.md index 8b81858f3786..47b2fbeac2cb 100644 --- a/content/communities/moderating-comments-and-conversations/managing-disruptive-comments.md +++ b/content/communities/moderating-comments-and-conversations/managing-disruptive-comments.md @@ -1,6 +1,6 @@ --- title: Managing disruptive comments -intro: 'You can {% ifversion fpt or ghec %}hide, edit,{% else %}edit{% endif %} or delete comments on issues, discussions, pull requests, and commits.' +intro: 'You can hide, edit, or delete comments on issues, discussions, pull requests, and commits.' redirect_from: - /articles/editing-a-comment - /articles/deleting-a-comment @@ -17,7 +17,7 @@ category: ## Hiding a comment -{% ifversion fpt or ghec %}Organization moderators, and anyone{% else %}Anyone{% endif %} with write access to a repository, can hide comments on issues, discussions, pull requests, and commits. +Organization moderators and anyone with write access to a repository, can hide comments on issues, discussions, pull requests, and commits. If a comment is off-topic, outdated, or resolved, you may want to hide a comment to keep a discussion focused or make a pull request easier to navigate and review. Hidden comments are minimized but people with read access to the repository can expand them. @@ -32,7 +32,7 @@ If a comment is off-topic, outdated, or resolved, you may want to hide a comment ## Unhiding a comment -{% ifversion fpt or ghec %}Organization moderators, and anyone{% else %}Anyone{% endif %} with write access to a repository, can unhide comments on issues, discussions, pull requests, and commits. +Organization moderators and anyone with write access to a repository, can unhide comments on issues, discussions, pull requests, and commits. 1. Navigate to the comment you'd like to unhide. 1. On the right side of the comment, click **{% octicon "fold" aria-hidden="true" aria-label="fold" %} Show comment**. @@ -44,7 +44,7 @@ If a comment is off-topic, outdated, or resolved, you may want to hide a comment Anyone with write access to a repository can edit comments on issues, discussions, pull requests, and commits. -It's appropriate to edit a comment and remove content that doesn't contribute to the conversation and violates your community's code of conduct{% ifversion fpt or ghec %} or {% data variables.product.github %}'s [Community Guidelines](/free-pro-team@latest/site-policy/github-terms/github-community-guidelines){% endif %}. +It's appropriate to edit a comment and remove content that doesn't contribute to the conversation and violates your community's code of conduct or {% data variables.product.github %}'s [Community Guidelines](/free-pro-team@latest/site-policy/github-terms/github-community-guidelines). Sometimes it may make sense to clearly indicate edits and their justification. @@ -71,7 +71,7 @@ Anyone with write access to a repository can delete comments on issues, discussi If a comment contains some constructive content that adds to the conversation in the issue or pull request, you can edit the comment instead. -Deleting a comment is your last resort as a moderator. It's appropriate to delete a comment if the entire comment adds no constructive content to a conversation and violates your community's code of conduct{% ifversion fpt or ghec %} or GitHub's [Community Guidelines](/free-pro-team@latest/site-policy/github-terms/github-community-guidelines){% endif %}. +Deleting a comment is your last resort as a moderator. It's appropriate to delete a comment if the entire comment adds no constructive content to a conversation and violates your community's code of conduct or GitHub's [Community Guidelines](/free-pro-team@latest/site-policy/github-terms/github-community-guidelines). Deleting a comment creates a timeline event that is visible to anyone with read access to the repository. However, the username of the person who deleted the comment is only visible to people with write access to the repository. For anyone without write access, the timeline event is anonymized. diff --git a/content/copilot/how-tos/copilot-on-github/set-up-copilot/enable-copilot/set-up-a-dedicated-enterprise-for-copilot-business.md b/content/copilot/how-tos/copilot-on-github/set-up-copilot/enable-copilot/set-up-a-dedicated-enterprise-for-copilot-business.md index 26229b09c6f4..27ab6f36cbe2 100644 --- a/content/copilot/how-tos/copilot-on-github/set-up-copilot/enable-copilot/set-up-a-dedicated-enterprise-for-copilot-business.md +++ b/content/copilot/how-tos/copilot-on-github/set-up-copilot/enable-copilot/set-up-a-dedicated-enterprise-for-copilot-business.md @@ -50,9 +50,15 @@ Provisioned users appear automatically in your enterprise's **People** list. You Group users to scale license assignment by creating enterprise teams. See [AUTOTITLE](/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/create-enterprise-teams). +## Convert your trial to a paid enterprise account + +To begin using {% data variables.copilot.copilot_business_short %} after your trial, convert to a paid enterprise account. See [AUTOTITLE](/enterprise-cloud@latest/admin/overview/setting-up-a-trial-of-github-enterprise-cloud#purchasing-github-enterprise). + ## Enable {% data variables.product.prodname_copilot_short %} for the enterprise -{% data reusables.copilot-business-for-non-ghe.enable-copilot %} +1. Ensure you are signed in as an enterprise administrator on {% data variables.product.github %}. +1. To purchase {% data variables.product.prodname_copilot %} for your enterprise, [contact {% data variables.product.github %}'s Sales team](https://github.com/enterprise/contact?ref_product=copilot&ref_type=engagement&ref_style=text). +1. A member of the Sales team will work with you to set up {% data variables.product.prodname_copilot_short %} for your enterprise. ## Assign {% data variables.product.prodname_copilot_short %} licenses @@ -60,10 +66,6 @@ Give people access to {% data variables.product.prodname_copilot_short %} by ass For detailed steps, see [AUTOTITLE](/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-access/grant-access#assigning-licenses-to-users-or-teams). -## Convert your trial to a paid enterprise account - -To continue using {% data variables.copilot.copilot_business_short %} after your trial, convert to a paid enterprise account. See [AUTOTITLE](/enterprise-cloud@latest/admin/overview/setting-up-a-trial-of-github-enterprise-cloud#purchasing-github-enterprise). - ## Next steps Help your developers start using {% data variables.product.prodname_copilot_short %} and measure its impact. See [AUTOTITLE](/copilot/tutorials/roll-out-at-scale/enable-developers/drive-adoption). diff --git a/content/migrations/elm/about-live-migrations.md b/content/migrations/elm/about-live-migrations.md new file mode 100644 index 000000000000..4c149e55dbbf --- /dev/null +++ b/content/migrations/elm/about-live-migrations.md @@ -0,0 +1,52 @@ +--- +title: About live migrations from GitHub Enterprise Server to GHE.com +shortTitle: About live migrations +intro: 'How do live migrations minimize downtime for developers?' +versions: + fpt: '*' + ghes: '*' + ghec: '*' +contentType: concepts +product: '{% data reusables.elm.ghes-version-requirement %}' +--- + +{% data reusables.elm.preview-note %} + +## What is {% data variables.product.prodname_elm %}? + +{% data variables.product.prodname_elm %} ({% data variables.product.prodname_elm_short %}) is a service for migrating repositories from {% data variables.product.prodname_ghe_server %} to {% data variables.enterprise.data_residency %} ({% data variables.enterprise.data_residency_site %}). It is operated using a command line tool on {% data variables.product.prodname_ghe_server %}. + +Migrations are "live" because users can continue using the source repository during most of the migration process. After the repository data is initially collected, webhooks check for changes to the repository, such as new commits or updates to settings. These changes are reported to {% data variables.product.prodname_elm_short %} and included in the migration. + +An {% data variables.product.prodname_elm_short %} migration includes a single repository. Organization-level data, such as organization settings, teams, and projects, are **not** included in the migration and must be reconfigured manually on the destination enterprise. + +## Differences from {% data variables.product.prodname_importer_proper_name %} + +{% data variables.product.prodname_elm_short %} and {% data variables.product.prodname_importer_proper_name %} (GEI) are separate tools that both support migrating repositories from {% data variables.product.prodname_ghe_server %} to {% data variables.enterprise.data_residency_site %}. + +The main benefits of {% data variables.product.prodname_elm_short %} are: + +* **Reduced developer downtime**: During a migration with GEI, developers lose access to the repository for the duration of the migration. This downtime creates risks like blocked deployments or stalled feature work. +* **Monorepo support**: {% data variables.product.prodname_elm_short %} is capable of migrating large, complex monorepos with deep histories. These often exceed the capacity of GEI. +* **Better visibility**: {% data variables.product.prodname_elm_short %} provides detailed repository-level visibility into migration progress, surfacing granular failures so that you can be confident the migrated repository is an accurate replica. + +However, because of the higher traffic load associated with live updates, {% data variables.product.prodname_elm_short %} supports fewer concurrent migrations than GEI: {% data reusables.elm.concurrent-migrations %} + +You may want to use both tools over the course of a platform migration, prioritizing the repositories that will benefit most from {% data variables.product.prodname_elm_short %}. + +## Overview of a migration + +Typically, a site administrator runs a migration using the `elm` CLI tool, in a terminal session over SSH. The operator must provide {% data variables.product.pat_generic_plural %} with access to both {% data variables.product.prodname_ghe_server %} and the destination enterprise. + +The high-level phases of a migration are: + +1. **Creation**: The site admin runs CLI commands to create and start the migration, specifying the source repository and destination. +1. **Preflight checks**: The migration service verifies parameters, tokens, network connectivity, and repository configuration. +1. **Backfill**: The {% data variables.product.prodname_elm_short %} tool does an initial crawl to capture all repository data and sends it to the migration service on the destination platform. During the backfill phase, webhooks check for live updates to the repository as the migration continues. +1. **Cutover**: The source repository is locked and any final live updates are sent to {% data variables.product.prodname_elm_short %}. This is the downtime period for developers. +1. **Completion**: The migration is finished. The site admin can check the data was migrated successfully. +1. **Follow-up**: An organization owner performs follow-up tasks on the destination enterprise, such as reconfiguring organization settings and reattributing activity to users. + +## Next steps + +To get ready to run a migration, see [AUTOTITLE](/migrations/elm/prepare-for-your-migration). diff --git a/content/migrations/elm/complete-your-migration.md b/content/migrations/elm/complete-your-migration.md new file mode 100644 index 000000000000..2a52b9db435d --- /dev/null +++ b/content/migrations/elm/complete-your-migration.md @@ -0,0 +1,46 @@ +--- +title: Completing your live migration from GitHub Enterprise Server to GHE.com +shortTitle: Complete your migration +intro: 'Complete follow-up tasks so users can start using the migrated repository.' +versions: + fpt: '*' + ghes: '*' + ghec: '*' +contentType: how-tos +permissions: 'Organization owners on {% data variables.enterprise.data_residency_site %}' +--- + +{% data reusables.elm.preview-note %} + +After you have run a migration with the `elm` CLI tool, there are some follow-up tasks to complete. + +## Restore users' access + +Because {% data variables.product.prodname_ghe_server %} and {% data variables.enterprise.data_residency_site %} use different provisioning and authentication systems, organization membership is not carried over between platforms. You will need to add users to the organization before you can reattribute activity to them in a migrated repository. + +1. If you created a new organization for the migration process, add members to the organization. You can do this manually, but many enterprises manage organization membership from their identity provider (IdP) by syncing enterprise teams with IdP groups. +1. Add organization members to the migrated repositories. + +## Reattribute activity to users + +{% data reusables.enterprise-migration-tool.about-mannequins %} For more information, see [AUTOTITLE](/migrations/overview/mannequins-and-user-activity). + +Once user accounts have been added to the organization on {% data variables.enterprise.data_residency_site %}, you can invite users to reclaim a mannequin's activity. You can do this in the browser or, with the {% data variables.product.prodname_gei_cli %} tool, reclaim mannequins in bulk without the invite process. + +### Reclaiming mannequins in the browser + +{% data reusables.elm.reclaim-mannequins-in-browser %} + +### Reclaiming mannequins in bulk + +You can install the {% data variables.product.prodname_gei_cli %} to reclaim mannequins in bulk. See [AUTOTITLE](/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/reclaiming-mannequins-for-github-enterprise-importer#reclaiming-mannequins-with-the-gei-extension). + +## Reattribute Git activity + +{% data reusables.elm.git-activity %} + +To reattribute Git activity on {% data variables.enterprise.data_residency_site %}, ensure the user's primary email address in your identity provider (IdP) matches the email address used for their commits. With {% data variables.product.prodname_emus %}, users cannot add email addresses to their user account on {% data variables.product.github %}, so users will not be able to reattribute their Git commits independently. + +## Recreate organization settings + +If you created a new organization for the migration process, restore settings such as policies, organization teams, and projects. diff --git a/content/migrations/elm/elm-cli-reference.md b/content/migrations/elm/elm-cli-reference.md new file mode 100644 index 000000000000..b74b873f85b6 --- /dev/null +++ b/content/migrations/elm/elm-cli-reference.md @@ -0,0 +1,67 @@ +--- +title: Enterprise Live Migrations CLI reference +shortTitle: ELM CLI reference +intro: 'Detailed usage information for the {% data variables.product.prodname_elm_short %} CLI tool.' +versions: + fpt: '*' + ghes: '*' + ghec: '*' +contentType: reference +--- + +{% data reusables.elm.preview-note %} + +## `elm migration` commands + +| Command | Description | +|---|---| +| `elm migration create` | Creates a new migration for a single source repository | +| `elm migration start --migration-id MIGRATION-ID` | Starts a migration | +| `elm migration status --migration-id MIGRATION-ID` | Shows the status, progress, cutover readiness, and timing of a migration | +| `elm migration list` | Lists all migrations and their statuses | +| `elm migration cancel --migration-id MIGRATION-ID` | Cancels a migration in progress | +| `elm migration cutover-to-destination --migration-id MIGRATION-ID` | Initiates the final cutover, locking the source repository and completing the migration | + +Some of these commands can take additional options. See the later sections in this article. + +## `elm migration create` options + +Create a new migration to prepare for repository export and import. + +| Flag | Required | Default | Description | +|---|---|---|---| +| `--source-org` | Yes | N/A | Slug of the source organization on {% data variables.product.prodname_ghe_server %} | +| `--source-repo` | Yes | N/A | Name of the source repository | +| `--target-org` | Yes | N/A | Slug of the destination organization on {% data variables.enterprise.data_residency_site %} | +| `--target-repo` | Yes | N/A | Name of the destination repository | +| `--target-api` | Yes | N/A | {% data reusables.elm.ghe-url-description %} | +| `--pat-name` | Yes | N/A | This must be set to a static string: `system-pat` | +| `--target-visibility` | No | `internal` | Visibility of the destination repository. Must be `private` or `internal`. Public repositories are not supported. | +| `--start` | No | `false` | Automatically starts the migration after creating it | + +## `elm migration list` options + +| Flag | Required | Default | Description | +|---|---|---|---| +| `--status` | No | N/A | Filters results by migration status. Valid values: `created`, `queued`, `in_progress`, `paused`, `completed`, `failed`, `terminated`. | +| `--page-size` | No | N/A | Number of results per page | +| `--after` | No | N/A | Cursor for pagination, from a previous response | + +## `elm migration cutover-to-destination` options + +| Flag | Required | Default | Description | +|---|---|---|---| +| `--migration-id` | Yes | N/A | The ID of a migration that is ready for cutover. | +| `--force` | No | `false` | By default, the command checks whether the migration target reports readiness before proceeding. Use `--force` to bypass this check when you are certain the migration state is correct. | + +## Global flags and variables + +The following properties can be provided either as environment variables or as flags on any command, with command flags taking priority. You should set these values _after_ applying the `ghe-config` configuration. + +| Variable | Flag | Required | Description | +|----------|------|----------|-------------| +| API_URL | `--api-url` | Yes | Must be set to `{% data reusables.elm.localhost-value %}`. | +| MIGRATION_MANAGER_HMAC_KEY | `--migration-manager-hmac-key` | Yes | Must be set to `{% data reusables.elm.hmac-key-value %}`. | +| MIGRATION_TARGET_URL | `--migration-target-url` | Yes | {% data reusables.elm.ghe-url-description %} | +| MIGRATION_TARGET_TOKEN | `--migration-target-token` | Yes | {% data reusables.elm.ghe-pat-description %} | +| DEBUG_HTTP | `--debug-http` | No | Set to `true` to print the HTTP method, URL, headers, and error response body for each request, for debugging purposes | diff --git a/content/migrations/elm/index.md b/content/migrations/elm/index.md new file mode 100644 index 000000000000..04149e7779be --- /dev/null +++ b/content/migrations/elm/index.md @@ -0,0 +1,17 @@ +--- +title: Live migrations from GitHub Enterprise Server to GHE.com +shortTitle: Live migrations (GHES to GHE.com) +intro: 'Use the Enterprise Live Migrations tool to migrate repositories with minimal downtime for developers.' +versions: + fpt: '*' + ghec: '*' + ghes: '*' +children: + - /about-live-migrations + - /prepare-for-your-migration + - /migrate-your-repository + - /complete-your-migration + - /troubleshooting + - /migrated-data-reference + - /elm-cli-reference +--- \ No newline at end of file diff --git a/content/migrations/elm/migrate-your-repository.md b/content/migrations/elm/migrate-your-repository.md new file mode 100644 index 000000000000..a9441a56bbe8 --- /dev/null +++ b/content/migrations/elm/migrate-your-repository.md @@ -0,0 +1,207 @@ +--- +title: Migrating your repository with Enterprise Live Migrations +shortTitle: Migrate your repository +intro: 'Migrate from {% data variables.product.prodname_ghe_server %} to {% data variables.enterprise.data_residency_site %} with minimal downtime.' +versions: + fpt: '*' + ghes: '*' + ghec: '*' +contentType: how-tos +product: '{% data reusables.elm.ghes-version-requirement %}' +permissions: 'Site administrators on {% data variables.product.prodname_ghe_server %} who are also enterprise owners on {% data variables.enterprise.data_residency_site %}.' +--- + +{% data reusables.elm.preview-note %} + +>[!TIP] As you follow this guide, you can refer to the [AUTOTITLE](/migrations/elm/elm-cli-reference) for more detailed usage information. If you encounter errors, see [AUTOTITLE](/migrations/elm/troubleshooting). + +## Prerequisites + +Make sure you're ready for your migration. See [AUTOTITLE](/migrations/elm/prepare-for-your-migration). + +## 1. Create access tokens + +You must authenticate with a {% data variables.product.pat_v1 %} for both the source and destination of the migration. For detailed instructions, see [AUTOTITLE](/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic). + +**Make a note of both tokens**, as you will need them in the next step. + +1. Create a {% data variables.product.pat_v1 %} on **{% data variables.product.prodname_ghe_server %}** with the following scopes. + + * `repo` + * `admin:org` + * `admin:repo_hook` + * `admin:org_hook` + +1. Create a {% data variables.product.pat_v1 %} on **{% data variables.enterprise.data_residency_site %}** with the following scopes. + + * `repo` + * `workflow` + * `admin:org` + * `admin:repo_hook` + * `admin:enterprise` + +1. If single sign-on is enforced on the target organization on {% data variables.enterprise.data_residency_site %}, authorize the {% data variables.enterprise.data_residency_site %} token. + +## 2. Configure {% data variables.product.prodname_ghe_server %} + +You must set some configuration on the {% data variables.product.prodname_ghe_server %} instance before performing a migration. These configuration values apply to all {% data variables.product.prodname_elm_short %} migrations. Developers on {% data variables.product.prodname_ghe_server %} may experience a brief downtime when you apply the new configuration. + +1. Access the {% data variables.product.prodname_ghe_server %} administrative shell over SSH. See [AUTOTITLE]({% ifversion not ghes %}/enterprise-server@latest{% endif %}/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh). +1. Set the following configuration variables with `ghe-config`. + + For example: `ghe-config app.elm-exporter.enabled true` + + | Variable | Set this to... | + |--------- | -------------- | + | `app.elm-exporter.enabled` | `true` | + | `app.elm.internal-webhooks-enabled` | `true` | + | `app.elm-exporter.webhooks-loopback-address-enabled` | `true` | + | `secrets.elm-exporter.migration-target-url` | {% data reusables.elm.ghe-url-description %} | + | `secrets.elm-exporter.migration-target-token` | The access token you created for {% data variables.enterprise.data_residency_site %}. | + | `secrets.elm-exporter.source-token` | The access token you created for {% data variables.product.prodname_ghe_server %}. | + | `secrets.elm-exporter.source-user` | The username associated with the {% data variables.product.prodname_ghe_server %} token (for example: `ghe-admin`). | + +1. If you **don't** already have migrations enabled and blob storage configured on the instance, you can configure them now. You can check your existing settings in in "Migrations" section of the Management Console (`HOSTNAME/setup/settings`). + + You can use the following default values, which will not introduce any unexpected functionality. + + ```shell copy + ghe-config app.migrations.enabled true + ``` + + ```shell copy + ghe-config secrets.migrations.blob-storage-type local-storage + ``` + +1. Apply the configuration. + + ```shell copy + ghe-config-apply + ``` + +## 3. Set required environment variables + +When the configuration has been applied, and before starting a migration, set required environment variables. For example: + +```shell +export API_URL='{% data reusables.elm.localhost-value %}' +``` + +>[!IMPORTANT] Copy the values for `API_URL` and `MIGRATION_MANAGER_HMAC_KEY` verbatim. The other variables are specific to your environment. + +| Variable | Required value | +| -------- | -------------- | +| API_URL | `{% data reusables.elm.localhost-value %}` | +| MIGRATION_MANAGER_HMAC_KEY | `{% data reusables.elm.hmac-key-value %}` | +| MIGRATION_TARGET_URL | {% data reusables.elm.ghe-url-description %} | +| MIGRATION_TARGET_TOKEN | {% data reusables.elm.ghe-pat-description %} | + +Any of these values can also be provided as CLI flags on any `elm` command, which will take priority over the variables. For example: `--api-url {% data reusables.elm.localhost-value %}`. + +## 4. Create a migration + +Create a new migration by specifying the source and target repository details. `--pat-name` must be set to `system-pat` as a static value. The other values are placeholders specific to your environment. + +>[!NOTE] The `target-org` can be new or existing. If the target organization doesn't already exist, it will be created during the migration. However, no settings from the source organization will be migrated. + +```shell copy +elm migration create \ + --source-org EXISTING-GHES-ORG \ + --source-repo EXISTING-GHES-REPO \ + --target-org GHEC-ORG \ + --target-repo NEW-GHEC-REPO \ + --target-api GHEC-API-URL \ + --pat-name system-pat +``` + +For example: + +``` shell +elm migration create \ + --source-org my-ghes-org \ + --source-repo my-ghes-repo \ + --target-org my-dr-org \ + --target-repo my-dr-repo \ + --target-api $MIGRATION_TARGET_URL \ + --pat-name system-pat +``` + +Optional flags: +* `--start`: If you're ready to start the migration immediately. +* `--target-visibility`: Migrated repositories are created with **internal** visibility by default, but you can specify `private`. + +### Save the migration ID + +You should see a response like the following: + +```json +{ + "migrationId": "2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9", + "expiresAt": "2026-02-11T21:49:33.619162159Z" +} +``` + +Export the `migrationId` as a variable, as you will need it for the next commands. For example: + +```shell +export MIGRATION_ID='2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9' +``` + +## 5. Start the migration + +If you didn't already start the migration, start it now using the migration ID you just saved. + +``` shell copy +elm migration start --migration-id $MIGRATION_ID +``` + +This launches the backfill and live update processes. {% data variables.product.prodname_elm_short %} is now collecting data from the source repository and listening for supported webhook events. + +## 6. Monitor the migration + +When the migration has started, you should see a new repository on {% data variables.enterprise.data_residency_site %}. During the migration, you will see the repository fill with an initial load of data and receive updates as developers continue to work in the source repository. + +Run the following command regularly to monitor the migration status. You will see a breakdown of the statuses of the source and target, and information on live data being migrated. + +``` shell copy +elm migration status --migration-id $MIGRATION_ID +``` + +The most important indicator in the response is the status in the **combinedState** object. When the status reaches `COMBINED_STATUS_READY_FOR_CUTOVER`, you should be ready to proceed to the next step. However, you will be alerted in the `displayMessage` if any individual resources failed to migrate, which you may need to investigate. + +For example: + +``` json + "combinedState": { + "status": "COMBINED_STATUS_READY_FOR_CUTOVER", + "displayMessage": "Ready for cutover (1 resources failed)", + "repositories": [ + { + "repositoryNwo": "new-test-org/my-new-repo", + "phase": "REPOSITORY_PHASE_READY_FOR_CUTOVER", + "displayStatus": "Ready for cutover (1 failed)" + } + ], + "readyForCutover": true, + "cutoverBlockers": [] + }, +``` + +Tips: + +* If you're running multiple migrations, you can check the status of all of them with `elm migration list`. This command shows in-progress migrations by default, but you can also filter by `--status`. +* If you encounter failure statuses that require attention, see [AUTOTITLE](/migrations/elm/troubleshooting#statuses-and-recommended-actions). + +## 7. Complete the migration + +When a migration is ready for cutover, you can complete the migration. The cutover process will lock the source repository, making it **permanently unavailable** for developers unless an administrator unlocks it. + +``` shell copy +elm migration cutover-to-destination --migration-id $MIGRATION_ID +``` + +Continue to monitor the migration. When you see the `MIGRATION_STATUS_COMPLETED` status at the top of the response, the migration is complete, although there are some follow-up tasks to give access to users from {% data variables.product.prodname_ghe_server %}. + +## Next steps + +Give users access to the new repository and reconcile activity with user accounts. See [AUTOTITLE](/migrations/elm/complete-your-migration). diff --git a/content/migrations/elm/migrated-data-reference.md b/content/migrations/elm/migrated-data-reference.md new file mode 100644 index 000000000000..9b078348dc67 --- /dev/null +++ b/content/migrations/elm/migrated-data-reference.md @@ -0,0 +1,157 @@ +--- +title: Migrated data for live migrations from GitHub Enterprise Server to GHE.com +shortTitle: Migrated data reference +intro: 'Which data and live updates are included in a live migration?' +versions: + fpt: '*' + ghes: '*' + ghec: '*' +contentType: reference +--- + +{% data reusables.elm.preview-note %} + +## Data that is migrated + +{% data variables.product.prodname_elm_short %} migrates almost all repository-level data. Organization-level resources, such as teams, projects, and organizations settings and webhooks, are excluded from the migration and must be configured manually on the target. + +The only organization-level action supported by {% data variables.product.prodname_elm_short %} is the creation of a target organization account if this does not already exist. + +### Repository settings and configuration + +| Resource | Notes | +|---|---| +| Repository metadata and settings | Visibility, description, default branch, and enabled features | +| Repository webhooks | Webhook configurations for the repository | +| Repository topics | Tags for categorizing the repository | +| Repository PR settings | Pull request merge and review settings | +| Actions settings | Repository-level GitHub Actions configuration, including allowed actions and permissions | +| Autolinks | Custom autolink references | +| Branch protections | Branch protection rules | +| Pages | GitHub Pages configuration | + +### Git data, LFS, and wikis + +| Resource | Notes | +|---|---| +| Git repository (refs, objects, history) | Includes all refs, objects, and commit history. The repository is kept up to date on the destination throughout the migration. | +| LFS objects | Git Large File Storage objects. Requires LFS to be enabled on the source {% data variables.product.prodname_ghe_server %} instance. | +| Wiki | The wiki Git repository | + +### Issues, comments, and reactions + +| Resource | Notes | +|---|---| +| Issues | Includes state, assignees, and body | +| Issue comments | All comments on issues | +| Issue reactions | Reactions on issues | +| Issue comment reactions | Reactions on issue comments | +| Issue labels | Label associations on issues | +| Issue events | Timeline events (assigned, labeled, closed, etc.) | +| Close issue references | Cross-references that close issues (e.g. "fixes #123") | + +### Pull requests, reviews, and threads + +| Resource | Notes | +|---|---| +| Pull requests | Includes state, reviewers, body, and draft status | +| PR reviews | Submitted reviews, including approved, changes-requested, and commented states | +| PR review comments | Inline code review comments | +| PR review threads | Threaded discussions, including resolved and unresolved state | +| PR comment reactions | Reactions on pull request review comments | +| PR labels | Label associations on pull requests | + +### Labels, milestones, releases, and CI + +| Resource | Notes | +|---|---| +| Labels | Label definitions, including name, color, and description | +| Milestones | Milestone definitions and state | +| Releases | Release metadata, including tag, name, body, and prerelease or draft status | +| Release reactions | Reactions on releases | +| Commit comments | Comments on individual commits | +| Commit status checks | CI/CD status checks on commits | +| Check runs | Check run results | +| Check suites | Check suite groupings | +| Team repository permissions | Team-to-repository permission associations | + +### Binary assets and file attachments + +| Resource | Notes | +|---|---| +| Release assets | Binary assets attached to releases, up to 2 GB per asset | +| Attachments | Image and video file attachments embedded in issue and pull request bodies | +| Repository files (non-media attachments) | Non-media file attachments, such as PDFs and text files, associated with issues and pull requests | + +### Users and mannequins + +| Resource | Notes | +|---|---| +| Mannequins | Every GitHub Enterprise Server user referenced in migrated data is represented as a mannequin: a placeholder identity with no organization membership or repository access. After your migration is complete, you can reclaim mannequins by associating them with real user accounts. | + +## Data that is not migrated + +### Repository data + +| Data | Notes | +|---|---| +| Repository defaults | N/A | +| Repository rulesets | Only branch protection rules are migrated. | +| Pull requests from forks | N/A | +| Pending pull request reviews | Only submitted reviews are migrated. | + +### Organization data + +Organization-level data such as the following is **not** migrated: + +* Settings +* Teams +* Projects +* Webhooks + +## Events included in live updates + +After the initial backfill completes, the exporter's **event listener** monitors webhooks on {% data variables.product.prodname_ghe_server %} to capture ongoing changes and forward them to the migration service on the target enterprise. + +The following tables document which resource types support live updates and which webhook actions are handled. + +| Resource type | Supported events | Unsupported events | +|---|---|---| +| **Repository** | `edited` | `archived`, `deleted`, `privatized`, `publicized`, `renamed`, `transferred`, `unarchived` | +| **Issues** | `assigned`, `closed`, `edited`, `labeled`, `opened`, `reopened`, `unassigned`, `unlabeled`, `milestoned`, `demilestoned` | `deleted`, `locked`, `pinned`, `transferred`, `unlocked`, `unpinned` | +| **Issue comment** | `created`, `edited` | `deleted` | +| **Pull request** | `assigned`, `closed`, `converted_to_draft`, `edited`, `labeled`, `opened`, `ready_for_review`, `reopened`, `unassigned`, `unlabeled`, `milestoned`, `demilestoned` | `auto_merge_disabled`, `auto_merge_enabled`, `dequeued`, `enqueued`, `locked`, `review_request_removed`, `review_requested`, `synchronize`, `unlocked` | +| **Pull request review** | `edited`, `submitted` | `dismissed` | +| **Pull request review comment** | `edited` | `created`, `deleted` | +| **Pull request review thread** | `resolved`, `unresolved` | N/A | +| **Label** | `created` | `deleted`, `edited` | +| **Release** | `created`, `edited`, `prereleased`, `published`, `released`, `unpublished` | `deleted` | +| **Milestone** | `closed`, `created`, `edited`, `opened` | `deleted` | +| **Branch protection rule** | `created`, `edited` | `deleted` | +| **Commit comment** | `created`, `edited` | `deleted` | +| **Page build** | All actions | N/A | +| **Commit status checks** | All actions | N/A | +| **Wiki** | All actions | N/A | +| **Autolink** | `created`, `deleted` | N/A | +| **Close issue reference** | `created` | N/A | +| **Reaction** | `created`, `deleted` | N/A | +| **Repository actions settings** | `updated` | N/A | +| **Repository webhook** | `created`, `updated` | N/A | + + +> [!NOTE] +> When a pull request review is submitted, {% data variables.product.prodname_elm_short %} imports the full review including all inline comments together. Inline comments that are part of an initial review submission are migrated correctly. However, **replies added to a review thread after the review has been submitted** are not captured as live updates and will not appear in the migrated repository. + +## Data not included in live updates + +The following are exported during initial backfill only and are **not** updated by webhooks: + +* Check runs +* Check suites +* GitHub Pages configuration + +## Rewriting of links and mentions + +References **within the source repository**, such as user mentions or links to issues and pull requests in the same repository, are rewritten so that they will still point to the correct resources after migration. + +References to **different repositories** (such as a link to an issue in the the `repo-2` repository from a pull request in `repo-1`) are **not** migrated and will point to the exact same destination after migration. This applies even if the referenced repository has already been migrated or is being migrated concurrently. diff --git a/content/migrations/elm/prepare-for-your-migration.md b/content/migrations/elm/prepare-for-your-migration.md new file mode 100644 index 000000000000..0b6d8ebd2e51 --- /dev/null +++ b/content/migrations/elm/prepare-for-your-migration.md @@ -0,0 +1,79 @@ +--- +title: Preparing for your live migration from GitHub Enterprise Server to GHE.com +shortTitle: Prepare for your migration +intro: 'Key questions to consider before getting started with {% data variables.product.prodname_elm %}.' +versions: + fpt: '*' + ghes: '*' + ghec: '*' +contentType: concepts +--- + +{% data reusables.elm.preview-note %} + +## Is our {% data variables.product.prodname_ghe_server %} instance ready? + + + + + +{% data variables.product.prodname_elm_short %} has been backported to supported releases. To use it, you must upgrade to one of the following minor versions or later: + +* `3.20.2` +* `3.19.6` +* `3.18.9` +* `3.17.15` + + + +Your {% data variables.product.prodname_ghe_server %} instance must also: + +* Use an **HTTPS** URL. HTTP URLs are not supported. +* Have migrations enabled and blob storage configured. You can check these settings in the "Migrations" section of the Management Console. If you don't already have these settings configured, we will explain how to set them to default values in [AUTOTITLE](/migrations/elm/migrate-your-repository). + +## What will our destination organization look like? + +You can migrate repositories to a new or existing organization on {% data variables.enterprise.data_residency_site %}. ELM creates the target organization if it doesn't already exist. + +A platform migration is a good opportunity to reconsider your organization and team structure. See [AUTOTITLE](/admin/concepts/enterprise-best-practices/organize-work). + +## Which repositories will we migrate? + +{% data variables.product.prodname_elm_short %} supports {% data reusables.elm.concurrent-migrations %} + +Plan which repositories you will migrate with {% data variables.product.prodname_elm_short %} first, and which you can migrate later or using a different migration tool. Repositories that are most likely to benefit from {% data variables.product.prodname_elm_short %} are: + +* Important repositories where long periods of downtime would disrupt your business +* Large monorepos that are too big for other migration tools + +Public repositories are not available on {% data variables.enterprise.data_residency_site %}, and these will be rejected by {% data variables.product.prodname_elm_short %}. You can change the visibility of these repositories on {% data variables.product.prodname_ghe_server %} before you start. + +You should check that the repositories you choose don't contain release assets that are over 2GB, as this is the limit for {% data variables.product.prodname_elm_short %}. + +## Who will run the migration? + +The person who runs an {% data variables.product.prodname_elm_short %} migration must: + +* Have site admin access to the {% data variables.product.prodname_ghe_server %} instance +* Be an enterprise owner on the {% data variables.enterprise.data_residency_site %} enterprise + +This person will need to perform the following tasks: + +* Before the migration, create {% data variables.product.pat_v1_plural %} on both the source and destination enterprise. +* During the migration, monitor the migration status and respond to issues. + +For concurrent {% data variables.product.prodname_elm_short %} migrations from a {% data variables.product.prodname_ghe_server %} instance, the same person must run all the `elm` commands, using the same tokens. + +After the migration, someone will need to perform some follow-up tasks on {% data variables.enterprise.data_residency_site %}. Any organization owner can do this. + +## What should my developers know? + +Before you start, communicate with developers that: + +* The repository is moving to a new location. Users can continue to use the source repository during the migration until the operator begins the final cutover to the new location. +* While the migration is in progress, developers should avoid force pushes to the repository, because these will disrupt the Git history in a way that {% data variables.product.prodname_elm_short %} cannot resolve. +* Certain actions that developers perform during the migration process may not be reflected in the migrated repository. For details, see the unsupported actions in [AUTOTITLE](/migrations/elm/migrated-data-reference#events-included-in-live-updates). + +## Next steps + +When you're ready to run a migration, see [AUTOTITLE](/migrations/elm/migrate-your-repository). diff --git a/content/migrations/elm/troubleshooting.md b/content/migrations/elm/troubleshooting.md new file mode 100644 index 000000000000..4ee7fbc5233b --- /dev/null +++ b/content/migrations/elm/troubleshooting.md @@ -0,0 +1,74 @@ +--- +title: Troubleshooting live migrations from GitHub Enterprise Server to GHE.com +shortTitle: Troubleshooting +intro: 'Advice for problems you may encounter with your migration.' +versions: + fpt: '*' + ghes: '*' + ghec: '*' +contentType: other +--- + +{% data reusables.elm.preview-note %} + +If your migration encounters a problem, check the migration status with `elm migration status --migration-id MIGRATION-ID` and review the error information. + +## Statuses and recommended actions + +| Status | Meaning | Recommended action | +|---|---|---| +| **Created** | The migration has been created but not yet started | Run `elm migration start` | +| **Queued** | The migration is waiting to start | Wait | +| **Exporting** | Data is being exported from the source | Monitor with `elm migration status` | +| **Processing** | Exported data is being imported to the destination | Monitor with `elm migration status` | +| **Ready for cutover** | The initial migration is complete and the migration is ready for cutover | When ready, run `elm migration cutover-to-destination` | +| **Cutting over** | The source repository is locked and remaining changes are being applied to the destination | Monitor; the status will transition to **Completed** | +| **Completed** | The migration has finished successfully | Verify the destination repository and reclaim mannequins | +| **Failed** | The migration encountered an unrecoverable failure | Investigate the error (see below) | +| **Paused** | The migration is paused | Resume the migration | +| **Terminated** | The migration was cancelled | N/A | +| **Degraded** | The destination is unreachable | Check network connectivity between the GitHub Enterprise Server appliance and GHE.com (see below) | + +## Migration status is "Failed" + +A migration enters the **Failed** status when an unrecoverable error prevents it from continuing. This is distinct from individual resources failing to import—a failed migration means the migration itself cannot proceed. + +To investigate, run `elm migration status --migration-id MIGRATION-ID` and review the error details in the response. Each failure includes a correlation ID in the format `(Correlation ID for Support: UUID)`. If you contact {% data variables.contact.github_support %}, provide this ID so the support team can investigate. + +After resolving the underlying issue, abort the failed migration with `elm migration cancel --migration-id MIGRATION-ID` and start a new migration. + +## Migration status is "Degraded" + +A **Degraded** status means the migration service on the {% data variables.product.prodname_ghe_server %} appliance cannot reach the destination enterprise. The migration continues on the source side, but the destination status is unknown. + +Check network connectivity between the {% data variables.product.prodname_ghe_server %} appliance and your subdomain of {% data variables.enterprise.data_residency_site %}, then run `elm migration status --migration-id MIGRATION-ID` again. The status response includes a timestamp for the last successful contact with the destination, which can help you assess how long the connectivity issue has been occurring. + +## Some resources failed to import + +Individual resources can fail to import without causing the overall migration to fail. You can see a count of failed resources in the output of `elm migration status --migration-id MIGRATION-ID`. + +Failed resources are only shown after all automatic retries have been exhausted, so any failures you see are confirmed as unresolvable without intervention. Review the error details in the status response: each failed resource in backfill or live updates will display `"state": "failed"`. + +If the number and types of failed resources are acceptable, you can proceed with cutover. If not, abort the migration, resolve the underlying issue, then start a new migration. + +## Cutover failed and the source repository is locked + +{% data reusables.elm.locked-repo %} + +## Migration must be restarted due to a force push + +If someone force-pushes to the default branch of the source repository while a migration is in progress, the Git synchronization between the source and destination breaks. Force pushes rewrite commit history in a way that cannot be reconciled incrementally. + +If this happens, abort the migration with `elm migration cancel --migration-id MIGRATION-ID` and start a new migration. Before restarting, communicate to your team that force pushes to the default branch are not permitted while a migration is active. + +## Access token was rejected + +If your migration fails with an authentication error, check that: + +* Both the source and destination tokens are {% data variables.product.pat_v1_plural %}. Fine-grained tokens are not supported. +* The tokens have the scopes specified in [AUTOTITLE](/migrations/elm/migrate-your-repository#1-create-access-tokens). +* If the destination organization enforces SAML single sign-on, the token must be authorized for SSO. + +## The source GHES URL was rejected + +{% data variables.product.prodname_elm %} requires the {% data variables.product.prodname_ghe_server %} URL to use HTTPS. If the URL is configured with HTTP, the migration will fail preflight validation. diff --git a/content/migrations/index.md b/content/migrations/index.md index c51b13592663..19f2092924a6 100644 --- a/content/migrations/index.md +++ b/content/migrations/index.md @@ -15,6 +15,7 @@ children: - /ado - /importing-source-code - /using-github-enterprise-importer + - /elm - /using-ghe-migrator - /troubleshooting includedCategories: diff --git a/content/migrations/overview/about-locked-repositories.md b/content/migrations/overview/about-locked-repositories.md index f4c814cc41cc..b964b610d8dc 100644 --- a/content/migrations/overview/about-locked-repositories.md +++ b/content/migrations/overview/about-locked-repositories.md @@ -35,6 +35,10 @@ While a migration is in progress, access to the destination repository is locked For information about how to unlock repositories that were locked by {% data variables.product.prodname_importer_proper_name %}, see [AUTOTITLE](/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/troubleshooting-your-migration-with-github-enterprise-importer#locked-repositories). +## Repositories locked by {% data variables.product.prodname_elm %} + +{% data reusables.elm.locked-repo %} + ## Repositories locked by the "Organization migrations" REST API When you call the [Start an organization migration](/rest/migrations/orgs#start-an-organization-migration) endpoint to generate a migration archive for a source repository, the repository is not locked by default. The repository is only locked if you set the `lock_repositories` parameter to `true`. diff --git a/content/migrations/overview/index.md b/content/migrations/overview/index.md index 49f4a15d8c8e..651555bcdd40 100644 --- a/content/migrations/overview/index.md +++ b/content/migrations/overview/index.md @@ -7,8 +7,10 @@ versions: ghec: '*' children: - /about-githubs-migration-tooling + - /migrations-within-github - /planning-your-migration-to-github - /migration-paths-to-github - /about-locked-repositories + - /mannequins-and-user-activity - /programmatically-importing-repositories --- diff --git a/content/migrations/overview/mannequins-and-user-activity.md b/content/migrations/overview/mannequins-and-user-activity.md new file mode 100644 index 000000000000..3fb3ca1d09fd --- /dev/null +++ b/content/migrations/overview/mannequins-and-user-activity.md @@ -0,0 +1,32 @@ +--- +title: Mannequins and user activity +intro: Mannequins are placeholder identities that users can reclaim after a migration. +versions: + fpt: '*' + ghes: '*' + ghec: '*' +category: + - Plan your migration +--- + +## What are mannequins? + +{% data reusables.enterprise-migration-tool.about-mannequins %} + +Each mannequin only has a display name, which comes from the display name in the source repository. Mannequins do not have organization membership or repository access. Mannequins always use the same avatar, a ghost octocat, and include a mannequin label following the display name. + +![Screenshot of the header of an issue comment. The commenter is labeled as a mannequin, and the "Mannequin" label is outlined in dark orange.](/assets/images/help/github-enterprise-importer/mannequin-example.png) + +Reclaiming is optional and can happen any time after a migration is finished. For this reason, you can allow your team to begin working in migrated repositories before reclaiming. + +{% data reusables.elm.git-activity %} + +## How can I reclaim mannequins? + +{% data reusables.enterprise-migration-tool.how-to-reclaim %} For instructions, see [AUTOTITLE](/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/reclaiming-mannequins-for-github-enterprise-importer). + +By default, reclaiming a mannequin will send an attribution invitation to the target user. The target user can choose to accept or reject the invitation. + +After a user accepts an attribution invitation, all contributions previously attributed to the mannequin will be attributed to the user instead. In future migrations to the same organization, any contributions from the same mannequin will be automatically reclaimed for the same user. + +If your organization uses {% data variables.product.prodname_emus %} and you choose to reclaim mannequins with the {% data variables.product.prodname_cli %}, you can optionally skip the invitation process, immediately reclaiming the mannequin without the user's approval. diff --git a/content/migrations/overview/migration-paths-to-github.md b/content/migrations/overview/migration-paths-to-github.md index ceda1a01dd91..0ae574d44b1e 100644 --- a/content/migrations/overview/migration-paths-to-github.md +++ b/content/migrations/overview/migration-paths-to-github.md @@ -25,7 +25,6 @@ In our recommendations, we'll assume that you want the highest level of fidelity You can review the scope and tooling for your migration to {% data variables.product.prodname_dotcom_the_website %}, which includes migrations to {% data variables.product.prodname_ghe_cloud %}. You can also review any additional information or caveats. * [{% data variables.product.prodname_ghe_server %} 3.4.1 or newer to {% data variables.product.prodname_dotcom_the_website %}](#github-enterprise-server-341-or-newer-to-githubcom) -* [{% data variables.product.prodname_ghe_server %} 3.4.0 or older to {% data variables.product.prodname_dotcom_the_website %}](#github-enterprise-server-340-or-older-to-githubcom) * [{% data variables.product.prodname_dotcom_the_website %} to {% data variables.product.prodname_dotcom_the_website %}](#githubcom-to-githubcom) * [Azure DevOps Services (Azure DevOps Cloud) to {% data variables.product.prodname_dotcom_the_website %}](#azure-devops-services-azure-devops-cloud-to-githubcom) * [Azure DevOps Server to {% data variables.product.prodname_dotcom_the_website %}](#azure-devops-server-to-githubcom) @@ -42,17 +41,6 @@ You can review the scope and tooling for your migration to {% data variables.pro ### {% data variables.product.prodname_ghe_server %} 3.4.1 or newer to {% data variables.product.prodname_dotcom_the_website %} -* **Scope:** Source, history, and metadata -* **Tooling:** {% data variables.product.prodname_importer_proper_name %} -* **More information:** - * [AUTOTITLE](/migrations/using-github-enterprise-importer) - * [{% data variables.product.prodname_expert_services %}](https://github.com/services/) website -* **Caveats:** - * {% data reusables.migrations.large-repositories-require-expert-services %} - * {% data reusables.migrations.migration-instructions-for-any-git-repository-to-githubcom %} - -### {% data variables.product.prodname_ghe_server %} 3.4.0 or older to {% data variables.product.prodname_dotcom_the_website %} - * **Scope:** Source, history, and metadata * **Tooling:** {% data variables.product.prodname_importer_proper_name %} * **More information:** @@ -170,8 +158,7 @@ Migrations to {% data variables.enterprise.data_residency_site %} use similar to Follow a link below to review the scope and tooling for your migration to {% data variables.enterprise.data_residency_site %}, plus any additional information or caveats. -* [{% data variables.product.prodname_ghe_server %} 3.4.1 or newer to {% data variables.enterprise.data_residency_site %}](#github-enterprise-server-341-or-newer-to-ghecom) -* [{% data variables.product.prodname_ghe_server %} 3.4.0 or older to {% data variables.enterprise.data_residency_site %}](#github-enterprise-server-340-or-older-to-ghecom) +* [{% data variables.product.prodname_ghe_server %} to {% data variables.enterprise.data_residency_site %}](#github-enterprise-server-to-ghecom) * [{% data variables.product.prodname_dotcom_the_website %} to {% data variables.enterprise.data_residency_site %}](#githubcom-to-ghecom) * [Azure DevOps Services (Azure DevOps Cloud) to {% data variables.enterprise.data_residency_site %}](#azure-devops-services-azure-devops-cloud-to-ghecom) * [Azure DevOps Server to {% data variables.enterprise.data_residency_site %}](#azure-devops-server-to-ghecom) @@ -185,23 +172,15 @@ Follow a link below to review the scope and tooling for your migration to {% dat * [Any Perforce repository to {% data variables.enterprise.data_residency_site %}](#any-perforce-repository-to-ghecom) * [Any other repository to {% data variables.enterprise.data_residency_site %}](#any-other-repository-to-ghecom) -### {% data variables.product.prodname_ghe_server %} 3.4.1 or newer to {% data variables.enterprise.data_residency_site %} +### {% data variables.product.prodname_ghe_server %} to {% data variables.enterprise.data_residency_site %} * **Scope:** Source, history, and metadata -* **Tooling:** {% data variables.product.prodname_importer_proper_name %} -* **More information:** - * [AUTOTITLE](/migrations/using-github-enterprise-importer) - * [{% data variables.product.prodname_expert_services %}](https://github.com/services/) website -* **Caveats:** - * {% data reusables.migrations.large-repositories-require-expert-services-ghecom %} - * {% data reusables.migrations.migration-instructions-for-any-git-repository-to-ghecom %} - -### {% data variables.product.prodname_ghe_server %} 3.4.0 or older to {% data variables.enterprise.data_residency_site %} - -* **Scope:** Source, history, and metadata -* **Tooling:** {% data variables.product.prodname_importer_proper_name %} +* **Tooling:** + * **Version 3.4.1 or later**: {% data variables.product.prodname_importer_proper_name %} + * **Version 3.17 or later (in supported patch releases)**: {% data variables.product.prodname_importer_proper_name %} or {% data variables.product.prodname_elm %} * **More information:** * [AUTOTITLE](/migrations/using-github-enterprise-importer) + * [AUTOTITLE](/migrations/elm/about-live-migrations) * [{% data variables.product.prodname_expert_services %}](https://github.com/services/) website * **Caveats:** * {% data reusables.migrations.large-repositories-require-expert-services-ghecom %} diff --git a/content/migrations/overview/migrations-within-github.md b/content/migrations/overview/migrations-within-github.md new file mode 100644 index 000000000000..7ce8ce7f1f78 --- /dev/null +++ b/content/migrations/overview/migrations-within-github.md @@ -0,0 +1,32 @@ +--- +title: About migrations between GitHub products +shortTitle: Migrations within GitHub +intro: 'Why should I move between {% data variables.product.github %} platforms, and what do I need to consider?' +versions: + fpt: '*' + ghes: '*' + ghec: '*' +category: + - Plan your migration +--- + +## When would I migrate between platforms? + +You can use {% data variables.product.github %}'s migration tools to move **between** {% data variables.product.github %} platforms. For example: + +* If you want to adopt {% data variables.enterprise.data_residency %}, you can migrate your enterprise to {% data variables.enterprise.data_residency_site %}. +* To use certain features on {% data variables.product.prodname_dotcom_the_website %}, such as {% data variables.product.prodname_emus %} or new billing models, you can migrate between enterprises on {% data variables.product.prodname_dotcom_the_website %}. +* To benefit from the simplified administration and new features of {% data variables.product.prodname_ghe_cloud %}, you can migrate from {% data variables.product.prodname_ghe_server %}. + +## Considerations for migrations to {% data variables.product.prodname_ghe_cloud %} + +* If you **already use {% data variables.product.prodname_ghe_cloud %}**: A {% data variables.product.prodname_enterprise %} plan entitles you to **only one** deployment of {% data variables.product.prodname_ghe_cloud %}. + + For example, if you already use {% data variables.product.prodname_dotcom_the_website %}, and you also want to migrate from {% data variables.product.prodname_ghe_server %} to {% data variables.enterprise.data_residency_site %}, your usage for both won't be covered under a single plan. +* If you're **migrating to {% data variables.product.prodname_emus %}**: You will need to integrate with an identity provider to manage user accounts. Check the level of support for your identity provider before you start. See [AUTOTITLE](/enterprise-cloud@latest/admin/managing-iam/understanding-iam-for-enterprises/about-enterprise-managed-users#identity-management-systems). +* If you're **migrating from {% data variables.product.prodname_ghe_server %}**: Be aware that {% data variables.product.company_short %} applies rate limits to certain actions, which are disabled by default on {% data variables.product.prodname_ghe_server %}. See [AUTOTITLE](/enterprise-cloud@latest/rest/using-the-rest-api/rate-limits-for-the-rest-api). +* If you're **migrating to {% data variables.enterprise.data_residency %}**: Be aware that certain features are unavailable, and some features require different or additional configuration. See [AUTOTITLE](/enterprise-cloud@latest/admin/data-residency/feature-overview-for-github-enterprise-cloud-with-data-residency). + +## Available tools + +For an overview of available tooling for your migration path, see [AUTOTITLE](/migrations/overview/migration-paths-to-github). diff --git a/content/migrations/overview/planning-your-migration-to-github.md b/content/migrations/overview/planning-your-migration-to-github.md index 8556611496d6..5d322381c07d 100644 --- a/content/migrations/overview/planning-your-migration-to-github.md +++ b/content/migrations/overview/planning-your-migration-to-github.md @@ -207,7 +207,7 @@ For example, suppose @octocat created an issue on {% data variables.location.pro The way that attribution works differs between tools: * If you’re using `ghe-migrator`, `gl-exporter`, or `bbs-exporter`, you will decide how you want to attribute data ahead of time and include a mapping file when you import your data. -* If you’re using {% data variables.product.prodname_importer_proper_name %}, data will be linked to placeholder identities called “mannequins”, and you can assign this history to real users after your data is migrated. For more information, see [AUTOTITLE](/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/reclaiming-mannequins-for-github-enterprise-importer). +* If you’re using {% data variables.product.prodname_importer_proper_name %} or {% data variables.product.prodname_elm %}, data will be linked to placeholder identities called “mannequins”, and you can assign this history to real users after your data is migrated. For more information, see [AUTOTITLE](/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/reclaiming-mannequins-for-github-enterprise-importer). ### Managing teams and permissions diff --git a/content/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/reclaiming-mannequins-for-github-enterprise-importer.md b/content/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/reclaiming-mannequins-for-github-enterprise-importer.md index cce84c5cf415..c05ce1b1eb8c 100644 --- a/content/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/reclaiming-mannequins-for-github-enterprise-importer.md +++ b/content/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/reclaiming-mannequins-for-github-enterprise-importer.md @@ -14,19 +14,7 @@ category: - Run an enterprise migration --- -## About mannequins - -{% data reusables.enterprise-migration-tool.about-mannequins %} - -Each mannequin only has a display name, which comes from the display name in the source repository. Mannequins do not have organization membership or repository access. Mannequins always use the same avatar, a ghost octocat, and include a mannequin label following the display name. - -![Screenshot of the header of an issue comment. The commenter is labeled as a mannequin, and the "Mannequin" label is outlined in dark orange.](/assets/images/help/github-enterprise-importer/mannequin-example.png) - -{% data reusables.enterprise-migration-tool.how-to-reclaim %} - -Reclaiming is optional and can happen any time after a migration is finished. For this reason, you can allow your team to begin working in migrated repositories before reclaiming. - -Mannequins are not used for Git commit attribution. For more details about commit attribution, see [Managing authorship for Git commits](#managing-authorship-for-git-commits) below. +{% data reusables.enterprise-migration-tool.about-mannequins %} For more information, see [AUTOTITLE](/migrations/overview/mannequins-and-user-activity). ## Reclaiming mannequins @@ -35,12 +23,6 @@ You can reclaim mannequins with {% data variables.product.prodname_cli %} (recom * [Reclaiming mannequins with the {% data variables.product.prodname_cli %} (recommended)](#reclaiming-mannequins-with-the-github-cli-recommended) * [Reclaiming mannequins in your browser](#reclaiming-mannequins-in-your-browser) -By default, reclaiming a mannequin will send an attribution invitation to the target user. - -The target user can choose to accept or reject the invitation. After a user accepts an attribution invitation, all contributions previously attributed to the mannequin will be attributed to the user instead. In future migrations to the same organization, any contributions from the same mannequin will be automatically reclaimed for the same user. - -If your organization uses {% data variables.product.prodname_emus %} and you choose to reclaim mannequins with the {% data variables.product.prodname_cli %}, you can optionally skip the invitation process, immediately reclaiming the mannequin without the user's approval. - > [!NOTE] > * You cannot reclaim mannequins after you have transferred a repository to another organization. If you wish to transfer a repository to another organization after your migration, you must reclaim the mannequins before the transfer. > * When reclaiming mannequins, you can only target existing organization members. Before attempting to reclaim a mannequin, verify that the {% data variables.product.prodname_dotcom %} user you want to invite is already added to the organization. @@ -161,17 +143,7 @@ If your migration source is Bitbucket Server, you can reclaim mannequins with th ### Reclaiming mannequins in your browser -{% data reusables.profile.access_org %} -{% data reusables.profile.org_settings %} -{% data reusables.enterprise-migration-tool.import-export-tab %} -1. To the right of the mannequin you want to reclaim, click **Reattribute**. -1. In the search field, type the username of the organization member you want to attribute the mannequin's contributions to, then click the member. - - > [!NOTE] - > You can only send attribution invitations to user accounts that are already members of the organization. - -1. Click **Invite**. -{% data reusables.enterprise-migration-tool.mannequin-reclaim-must-accept %} +{% data reusables.elm.reclaim-mannequins-in-browser %} ## Viewing the status of your attribution invitations @@ -190,7 +162,7 @@ You can view the status of all attribution invitations for your organization. ## Managing authorship for Git commits -Authorship for Git commits is not associated with mannequins and cannot be attributed to {% data variables.product.prodname_dotcom %} users by reclaiming mannequins. Instead, commit authorship is attributed to user accounts on {% data variables.product.prodname_dotcom %} based on the email address that was used to author the commit in Git. +{% data reusables.elm.git-activity %} In many cases, users can reattribute commits to themselves by adding the email address used to author the commit to their user account on {% data variables.product.prodname_dotcom %}. For more information, see [AUTOTITLE](/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/adding-an-email-address-to-your-github-account). diff --git a/content/migrations/using-github-enterprise-importer/migrating-between-github-products/about-migrations-between-github-products.md b/content/migrations/using-github-enterprise-importer/migrating-between-github-products/about-migrations-between-github-products.md index a5b6a9370451..7e3e83d10da4 100644 --- a/content/migrations/using-github-enterprise-importer/migrating-between-github-products/about-migrations-between-github-products.md +++ b/content/migrations/using-github-enterprise-importer/migrating-between-github-products/about-migrations-between-github-products.md @@ -1,5 +1,5 @@ --- -title: About migrations between GitHub products +title: About migrations between GitHub products with {% data variables.product.prodname_importer_proper_name %} shortTitle: About migrations intro: 'Learn which data {% data variables.product.prodname_importer_proper_name %} can migrate between {% data variables.product.company_short %} products.' versions: @@ -8,18 +8,13 @@ versions: ghec: '*' category: - Understand enterprise migration tools +allowTitleToDifferFromFilename: true --- ## About migrations between {% data variables.product.company_short %} products With {% data variables.product.prodname_importer_proper_name %}, you can migrate data from {% data variables.product.prodname_ghe_server %} to {% data variables.product.prodname_ghe_cloud %}, or migrate data from {% data variables.product.prodname_dotcom_the_website %} to another account on {% data variables.product.prodname_ghe_cloud %}. -For example, {% data variables.product.prodname_importer_proper_name %} can help your company to: - -* Adopt {% data variables.enterprise.data_residency %} by migrating your enterprise to {% data variables.enterprise.data_residency_site %} -* Adopt certain features on {% data variables.product.prodname_dotcom_the_website %}, such as {% data variables.product.prodname_emus %} or new billing models, by migrating between enterprises on {% data variables.product.prodname_dotcom_the_website %} -* Benefit from simplified administration and new features by migrating from {% data variables.product.prodname_ghe_server %} to {% data variables.product.prodname_ghe_cloud %} - If your migration source is an account on {% data variables.product.prodname_dotcom_the_website %}, you can migrate individual repositories between organizations, or migrate entire organizations between enterprises. If your migration source is {% data variables.product.prodname_ghe_server %}, you can migrate individual repositories. The data that {% data variables.product.prodname_importer_proper_name %} migrates depends on the source of the migration and whether you are migrating a repository or organization. @@ -28,17 +23,6 @@ The data that {% data variables.product.prodname_importer_proper_name %} migrate {% data reusables.enterprise-migration-tool.repository-migrations-bypass %} {% endif %} -## Considerations for migrations to {% data variables.product.prodname_ghe_cloud %} - -Before you use {% data variables.product.prodname_importer_proper_name %}, understand the following considerations: - -* If you **already use {% data variables.product.prodname_ghe_cloud %}**: A {% data variables.product.prodname_enterprise %} plan entitles you to one deployment of {% data variables.product.prodname_ghe_cloud %}. - - For example, if you already use {% data variables.product.prodname_dotcom_the_website %}, and you also want to migrate from {% data variables.product.prodname_ghe_server %} to {% data variables.enterprise.data_residency_site %}, your usage for both won't be covered under a single plan. -* If you're **migrating to {% data variables.product.prodname_emus %}**: You will need to integrate with an identity provider to manage user accounts. Check the level of support for your identity provider before you start. See [AUTOTITLE](/enterprise-cloud@latest/admin/managing-iam/understanding-iam-for-enterprises/about-enterprise-managed-users#identity-management-systems). -* If you're **migrating from {% data variables.product.prodname_ghe_server %}**: Be aware that {% data variables.product.company_short %} applies rate limits to certain actions, which are disabled by default on {% data variables.product.prodname_ghe_server %}. See [AUTOTITLE](/enterprise-cloud@latest/rest/using-the-rest-api/rate-limits-for-the-rest-api). -* If you're **migrating to {% data variables.enterprise.data_residency %}**: Be aware that certain features are unavailable, and some features require different or additional configuration. See [AUTOTITLE](/enterprise-cloud@latest/admin/data-residency/feature-overview-for-github-enterprise-cloud-with-data-residency). - ## Data that is migrated from {% data variables.product.prodname_ghe_server %} To migrate from {% data variables.product.prodname_ghe_server %} (GHES), you must have GHES version 3.4.1 or higher. The data that is migrated depends on the version you're using. diff --git a/content/migrations/using-github-enterprise-importer/understanding-github-enterprise-importer/about-github-enterprise-importer.md b/content/migrations/using-github-enterprise-importer/understanding-github-enterprise-importer/about-github-enterprise-importer.md index bb76258e8558..4417179cd051 100644 --- a/content/migrations/using-github-enterprise-importer/understanding-github-enterprise-importer/about-github-enterprise-importer.md +++ b/content/migrations/using-github-enterprise-importer/understanding-github-enterprise-importer/about-github-enterprise-importer.md @@ -41,6 +41,10 @@ You can migrate on a repository-by-repository basis or, if your migration source {% data reusables.enterprise-migration-tool.supported-migration-paths %} +### Alternative tooling for {% data variables.product.prodname_ghe_server %} to {% data variables.enterprise.data_residency_site %} + +In supported patch releases in version 3.17 and later, {% data variables.product.prodname_elm %} is available as an alternative tool for migrations from {% data variables.product.prodname_ghe_server %} to {% data variables.enterprise.data_residency_site %}. {% data variables.product.prodname_elm %} reduces downtime for developers during the migration and offers better support for large monorepos. See [AUTOTITLE](/migrations/elm/about-live-migrations). + ## Getting started To learn more about the migration path you require, and the data that {% data variables.product.prodname_importer_proper_name %} migrates, see the following articles. diff --git a/data/features/push-protection-repo-exemptions.yml b/data/features/push-protection-repo-exemptions.yml index b9038f40694e..4c615d1bdd7a 100644 --- a/data/features/push-protection-repo-exemptions.yml +++ b/data/features/push-protection-repo-exemptions.yml @@ -3,4 +3,4 @@ versions: fpt: '*' ghec: '*' - ghes: '>3.21' + ghes: '>3.20' diff --git a/data/release-notes/enterprise-server/3-16/18.yml b/data/release-notes/enterprise-server/3-16/18.yml new file mode 100644 index 000000000000..1de4a355f523 --- /dev/null +++ b/data/release-notes/enterprise-server/3-16/18.yml @@ -0,0 +1,77 @@ +date: '2026-05-07' +sections: + features: + - | + To prevent Redis replication failures in clusters with high write volumes, administrators can configure Redis replication backlog size and client output buffer limits via `ghe-config`. Previously, these settings used fixed defaults that could cause replica disconnections when write throughput exceeded buffer limits, resulting in continuous full-resync loops. Changes take effect after running a configuration run. + security_fixes: + - | + **HIGH**: An attacker could exploit a server-side request forgery (SSRF) vulnerability in the notebook viewer to access internal services by exploiting URL parser confusion between the validation layer and the HTTP request library. This attack required network access to the GHES instance with private mode disabled. The vulnerability was addressed by aligning URL parsing between the validation and request layers and adding explicit validation of URL scheme, port, and userinfo components. GitHub has requested CVE ID [CVE-2026-8034](https://www.cve.org/cverecord?id=CVE-2026-8034) for this vulnerability, which was reported via the [GitHub Bug Bounty program](https://bounty.github.com). + - | + **MEDIUM**: An attacker could cause a denial of service on the instance by sending crafted requests with deeply nested JSON payloads to an unauthenticated API endpoint. To mitigate this issue, GitHub has added maximum size and depth validation to the stats endpoint. GitHub has requested CVE ID [CVE-2026-7541](https://www.cve.org/cverecord?id=CVE-2026-7541) for this vulnerability, which was reported via the [GitHub Bug Bounty](https://bounty.github.com/) program. + - | + **MEDIUM**: An attacker could create a local user account on a GitHub Enterprise Server instance configured with an external authentication provider, bypassing the identity provider entirely. The signup endpoint did not properly enforce the external authentication restriction, allowing account creation and session establishment without identity provider validation. The created account was limited to the default base permissions configured on the instance. GitHub has requested CVE ID [CVE-2026-6736](https://www.cve.org/cverecord?id=CVE-2026-6736) for this vulnerability. + bugs: + - | + Administrators who cancelled `ghe-live-migrations` (Ctrl+C or SIGTERM) during a live upgrade found that the CLI exited but the live-upgrade container continued running in the background. The container now stops gracefully when the command is interrupted. + - | + On instances with high push activity, commits did not appear in pull requests for minutes to hours, webhooks were delayed, and pull request state appeared stale. The stream processor service ran as a single process per node and could not scale horizontally to handle message volume. + - | + When initially configuring GitHub Actions with OIDC authentication, the configuration failed with an error indicating that OIDC was not enabled. + - | + The metrics page for secret scanning and push protection on security overview failed to load with an encoding error when pagination cursors contained binary data that could not be converted from UTF-8 to ASCII. + - | + On the secret scanning alert page for a generic secret, a feedback banner linked to a survey that no longer exists. + changes: + - | + The `ghe-cluster-hotpatch` command supports the `--parallel` flag. This flag executes the rollover stage in parallel across all nodes in a cluster, saving a significant amount of time during upgrades of large clusters. + - | + To prevent collectd memory exhaustion and OOM kills caused by write queue growth, administrators can configure collectd write queue limits and memory caps via `ghe-config`. Previously, tuning these settings required manual edits to collectd.conf and systemd configuration files. Changes take effect after running a configuration apply. + - | + When a user exports repositories using the migrations REST API, tarballs are staged in the data volume before being uploaded to blob storage. This location provides more disk capacity than the root volume, which was the previous staging location. + known_issues: + - | + During an upgrade of GitHub Enterprise Server, custom firewall rules are removed. If you use custom firewall rules, you must reapply them after upgrading. + - | + During the validation phase of a configuration run, a `No such object` error may occur for the Notebook and Viewscreen services. This error can be ignored as the services should still correctly start. + - | + If the root site administrator is locked out of the Management Console after failed login attempts, the account does not unlock automatically after the defined lockout time. Someone with administrative SSH access to the instance must unlock the account using the administrative shell. See [AUTOTITLE](/admin/administering-your-instance/administering-your-instance-from-the-web-ui/troubleshooting-access-to-the-management-console#unlocking-the-root-site-administrator-account). + - | + On an instance with the HTTP `X-Forwarded-For` header configured for use behind a load balancer, all client IP addresses in the instance's audit log erroneously appear as 127.0.0.1. + - | + {% data reusables.release-notes.large-adoc-files-issue %} + - | + Admin stats REST API endpoints may timeout on appliances with many users or repositories. Retrying the request until data is returned is advised. + - | + When following the steps for [Replacing the primary MySQL node](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-the-primary-mysql-node), step 14 (running `ghe-cluster-config-apply`) might fail with errors. If this occurs, re-running `ghe-cluster-config-apply` is expected to succeed. + - | + Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps. + - | + {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %} + - | + When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a nightly scheduled job. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`. + - | + An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning. + - | + When enabling automatic update checks for the first time in the Management Console, the status is not dynamically reflected until the "Updates" page is reloaded. + - | + When restoring from a backup snapshot, a large number of `mapper_parsing_exception` errors may be displayed. + - | + When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration. + - | + Admins setting up cluster high availability (HA) may encounter a spokes error when running `ghe-cluster-repl-status` if a new organization and repositories are created before using the `ghe-cluster-repl-bootstrap` command. To avoid this issue, complete the cluster HA setup with `ghe-cluster-repl-bootstrap` before creating new organizations and repositories. + - | + In a cluster, the host running restore requires access the storage nodes via their private IPs. + - | + On an instance hosted on Azure, commenting on an issue via email means the comment is not added to the issue. + - | + After a restore, existing outside collaborators cannot be added to repositories in a new organization. This issue can be resolved by running `/usr/local/share/enterprise/ghe-es-search-repair` on the appliance. + - | + After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. + - | + Unexpected elements may appear in the UI on the repo overview page for locked repositories. + - | + Audit log entries for pre-receive hooks that have been rejected may not be recorded. + - | + When applying an enterprise security configuration to all repositories (for example, enabling secret scanning or code scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. + - | + GitHub Enterprise Server releases shipped with mismatched Git versions between containers. diff --git a/data/release-notes/enterprise-server/3-17/15.yml b/data/release-notes/enterprise-server/3-17/15.yml new file mode 100644 index 000000000000..b265bce08dca --- /dev/null +++ b/data/release-notes/enterprise-server/3-17/15.yml @@ -0,0 +1,89 @@ +date: '2026-05-07' +sections: + features: + - | + Site administrators can use the Enterprise Live Migrations (ELM) service to migrate repositories from GitHub Enterprise Server to a data-resident enterprise on GHE.com. Live migrations carry less downtime for developers than other migration tools, because the source repository is only locked during the cutover phase. This feature is in public preview and subject to change. See [AUTOTITLE](/migrations/elm/about-live-migrations). + - | + To prevent Redis replication failures in clusters with high write volumes, administrators can configure Redis replication backlog size and client output buffer limits via `ghe-config`. Previously, these settings used fixed defaults that could cause replica disconnections when write throughput exceeded buffer limits, resulting in continuous full-resync loops. Changes take effect after running a configuration run. + - | + The capability to configure multiple data disks to host MySQL and repository data is now generally available. This applies to standalone, and high-availability topologies, and it is generally available in the latest patch versions of 3.17, 3.18, 3.19, and 3.20. See [AUTOTITLE](/admin/monitoring-and-managing-your-instance/multiple-data-disks/configuring-multiple-data-disks). + security_fixes: + - | + **HIGH**: An attacker could exploit a server-side request forgery (SSRF) vulnerability in the notebook viewer to access internal services by exploiting URL parser confusion between the validation layer and the HTTP request library. This attack required network access to the GHES instance with private mode disabled. The vulnerability was addressed by aligning URL parsing between the validation and request layers and adding explicit validation of URL scheme, port, and userinfo components. GitHub has requested CVE ID [CVE-2026-8034](https://www.cve.org/cverecord?id=CVE-2026-8034) for this vulnerability, which was reported via the [GitHub Bug Bounty program](https://bounty.github.com). + - | + **MEDIUM**: An attacker could cause a denial of service on the instance by sending crafted requests with deeply nested JSON payloads to an unauthenticated API endpoint. To mitigate this issue, GitHub has added maximum size and depth validation to the stats endpoint. GitHub has requested CVE ID [CVE-2026-7541](https://www.cve.org/cverecord?id=CVE-2026-7541) for this vulnerability, which was reported via the [GitHub Bug Bounty](https://bounty.github.com/) program. + - | + **MEDIUM**: An attacker could create a local user account on a GitHub Enterprise Server instance configured with an external authentication provider, bypassing the identity provider entirely. The signup endpoint did not properly enforce the external authentication restriction, allowing account creation and session establishment without identity provider validation. The created account was limited to the default base permissions configured on the instance. GitHub has requested CVE ID [CVE-2026-6736](https://www.cve.org/cverecord?id=CVE-2026-6736) for this vulnerability. + bugs: + - | + Users experienced failures with token-based authentication after the authnd service started but could not bind its HTTP port, leaving the service running but unable to serve requests. + - | + Administrators who cancelled `ghe-live-migrations` (Ctrl+C or SIGTERM) during a live upgrade found that the CLI exited but the live-upgrade container continued running in the background. The container now stops gracefully when the command is interrupted. + - | + On instances with high push activity, commits did not appear in pull requests for minutes to hours, webhooks were delayed, and pull request state appeared stale. The stream processor service ran as a single process per node and could not scale horizontally to handle message volume. + - | + When initially configuring GitHub Actions with OIDC authentication, the configuration failed with an error indicating that OIDC was not enabled. + - | + On instances using Enterprise teams, background jobs for enterprise team organization reconciliation accumulated in the queue and repeatedly failed when organization teams or team mappings were deleted while reconciliation jobs were running. This caused elevated latency for other background jobs. + - | + On an instance with SAML authentication and GitHub Pages configured, users were redirected to the root of the instance instead of their intended destination after completing SAML authentication. + - | + When delegated dismissal for secret scanning was enabled, users could submit dismissal requests for already-closed secret scanning alerts. These requests could not be reviewed or resolved via the UI, leaving alerts in a "request pending" state. + - | + The metrics page for secret scanning and push protection on security overview failed to load with an encoding error when pagination cursors contained binary data that could not be converted from UTF-8 to ASCII. + - | + On the secret scanning alert page for a generic secret, a feedback banner linked to a survey that no longer exists. + - | + When exporting bot-initiated issue events for migrations, bot users were not resolved to a valid URL. + changes: + - | + The `ghe-cluster-hotpatch` command supports the `--parallel` flag. This flag executes the rollover stage in parallel across all nodes in a cluster, saving a significant amount of time during upgrades of large clusters. + - | + To prevent collectd memory exhaustion and OOM kills caused by write queue growth, administrators can configure collectd write queue limits and memory caps via `ghe-config`. Previously, tuning these settings required manual edits to collectd.conf and systemd configuration files. Changes take effect after running a configuration apply. + known_issues: + - | + During an upgrade of GitHub Enterprise Server, custom firewall rules are removed. If you use custom firewall rules, you must reapply them after upgrading. + - | + During the validation phase of a configuration run, a `No such object` error may occur for the Notebook and Viewscreen services. This error can be ignored as the services should still correctly start. + - | + If the root site administrator is locked out of the Management Console after failed login attempts, the account does not unlock automatically after the defined lockout time. Someone with administrative SSH access to the instance must unlock the account using the administrative shell. See [AUTOTITLE](/admin/administering-your-instance/administering-your-instance-from-the-web-ui/troubleshooting-access-to-the-management-console#unlocking-the-root-site-administrator-account). + - | + On an instance with the HTTP `X-Forwarded-For` header configured for use behind a load balancer, all client IP addresses in the instance's audit log erroneously appear as 127.0.0.1. + - | + {% data reusables.release-notes.large-adoc-files-issue %} + - | + Admin stats REST API endpoints may timeout on appliances with many users or repositories. Retrying the request until data is returned is advised. + - | + When following the steps for [Replacing the primary MySQL node](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-the-primary-mysql-node), step 14 (running `ghe-cluster-config-apply`) might fail with errors. If this occurs, re-running `ghe-cluster-config-apply` is expected to succeed. + - | + Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps. + - | + {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %} + - | + When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a nightly scheduled job. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`. + - | + An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning. + - | + When enabling automatic update checks for the first time in the Management Console, the status is not dynamically reflected until the "Updates" page is reloaded. + - | + When restoring from a backup snapshot, a large number of `mapper_parsing_exception` errors may be displayed. + - | + When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration. + - | + Admins setting up cluster high availability (HA) may encounter a spokes error when running `ghe-cluster-repl-status` if a new organization and repositories are created before using the `ghe-cluster-repl-bootstrap` command. To avoid this issue, complete the cluster HA setup with `ghe-cluster-repl-bootstrap` before creating new organizations and repositories. + - | + In a cluster, the host running restore requires access the storage nodes via their private IPs. + - | + On an instance hosted on Azure, commenting on an issue via email means the comment is not added to the issue. + - | + After a restore, existing outside collaborators cannot be added to repositories in a new organization. This issue can be resolved by running `/usr/local/share/enterprise/ghe-es-search-repair` on the appliance. + - | + After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. + - | + Unexpected elements may appear in the UI on the repository overview page for locked repositories. + - | + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + - | + When applying an enterprise security configuration to all repositories (for example, enabling secret scanning or code scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. + - | + GitHub Enterprise Server releases shipped with mismatched Git versions between containers. diff --git a/data/release-notes/enterprise-server/3-18/9.yml b/data/release-notes/enterprise-server/3-18/9.yml new file mode 100644 index 000000000000..7e727d37a1a1 --- /dev/null +++ b/data/release-notes/enterprise-server/3-18/9.yml @@ -0,0 +1,95 @@ +date: '2026-05-07' +sections: + features: + - | + Site administrators can use the Enterprise Live Migrations (ELM) service to migrate repositories from GitHub Enterprise Server to a data-resident enterprise on GHE.com. Live migrations carry less downtime for developers than other migration tools, because the source repository is only locked during the cutover phase. This feature is in public preview and subject to change. See [AUTOTITLE](/migrations/elm/about-live-migrations). + - | + To prevent Redis replication failures in clusters with high write volumes, administrators can configure Redis replication backlog size and client output buffer limits via `ghe-config`. Previously, these settings used fixed defaults that could cause replica disconnections when write throughput exceeded buffer limits, resulting in continuous full-resync loops. Changes take effect after running a configuration run. + - | + The capability to configure multiple data disks to host MySQL and repository data is now generally available. This applies to standalone, and high-availability topologies, and it is generally available in the latest patch versions of 3.17, 3.18, 3.19, and 3.20. See [AUTOTITLE](/admin/monitoring-and-managing-your-instance/multiple-data-disks/configuring-multiple-data-disks). + security_fixes: + - | + **HIGH**: An attacker could exploit a server-side request forgery (SSRF) vulnerability in the notebook viewer to access internal services by exploiting URL parser confusion between the validation layer and the HTTP request library. This attack required network access to the GHES instance with private mode disabled. The vulnerability was addressed by aligning URL parsing between the validation and request layers and adding explicit validation of URL scheme, port, and userinfo components. GitHub has requested CVE ID [CVE-2026-8034](https://www.cve.org/cverecord?id=CVE-2026-8034) for this vulnerability, which was reported via the [GitHub Bug Bounty program](https://bounty.github.com). + - | + **MEDIUM**: An attacker could cause a denial of service on the instance by sending crafted requests with deeply nested JSON payloads to an unauthenticated API endpoint. To mitigate this issue, GitHub has added maximum size and depth validation to the stats endpoint. GitHub has requested CVE ID [CVE-2026-7541](https://www.cve.org/cverecord?id=CVE-2026-7541) for this vulnerability, which was reported via the [GitHub Bug Bounty](https://bounty.github.com/) program. + - | + **MEDIUM**: An attacker could create a local user account on a GitHub Enterprise Server instance configured with an external authentication provider, bypassing the identity provider entirely. The signup endpoint did not properly enforce the external authentication restriction, allowing account creation and session establishment without identity provider validation. The created account was limited to the default base permissions configured on the instance. GitHub has requested CVE ID [CVE-2026-6736](https://www.cve.org/cverecord?id=CVE-2026-6736) for this vulnerability. + bugs: + - | + Users experienced failures with token-based authentication after the authnd service started but could not bind its HTTP port, leaving the service running but unable to serve requests. + - | + Administrators who cancelled `ghe-live-migrations` (Ctrl+C or SIGTERM) during a live upgrade found that the CLI exited but the live-upgrade container continued running in the background. The container now stops gracefully when the command is interrupted. + - | + Administrators found that SSH settings for agents on cloud platforms (such as Googles guest agent) did not persist after upgrading GitHub Enterprise Server, requiring reconfiguration after each upgrade. These settings are now carried over between upgrades. + - | + On instances with high push activity, commits did not appear in pull requests for minutes to hours, webhooks were delayed, and pull request state appeared stale. The stream processor service ran as a single process per node and could not scale horizontally to handle message volume. + - | + When initially configuring GitHub Actions with OIDC authentication, the configuration failed with an error indicating that OIDC was not enabled. + - | + On instances configured for high availability, GitHub Actions settings could not be changed through the Management Console. + - | + On instances using Enterprise teams, background jobs for enterprise team organization reconciliation accumulated in the queue and repeatedly failed when organization teams or team mappings were deleted while reconciliation jobs were running. This caused elevated latency for other background jobs. + - | + On an instance with SAML authentication and GitHub Pages configured, users were redirected to the root of the instance instead of their intended destination after completing SAML authentication. + - | + When delegated dismissal for secret scanning was enabled, users could submit dismissal requests for already-closed secret scanning alerts. These requests could not be reviewed or resolved via the UI, leaving alerts in a "request pending" state. + - | + The metrics page for secret scanning and push protection on security overview failed to load with an encoding error when pagination cursors contained binary data that could not be converted from UTF-8 to ASCII. + - | + On the secret scanning alert page for a generic secret, a feedback banner linked to a survey that no longer exists. + - | + When exporting bot-initiated issue events for migrations, bot users were not resolved to a valid URL. + changes: + - | + The `ghe-cluster-hotpatch` command supports the `--parallel` flag. This flag executes the rollover stage in parallel across all nodes in a cluster, saving a significant amount of time during upgrades of large clusters. + - | + To prevent collectd memory exhaustion and OOM kills caused by write queue growth, administrators can configure collectd write queue limits and memory caps via `ghe-config`. Previously, tuning these settings required manual edits to collectd.conf and systemd configuration files. Changes take effect after running a configuration apply. + known_issues: + - | + During an upgrade of GitHub Enterprise Server, custom firewall rules are removed. If you use custom firewall rules, you must reapply them after upgrading. + - | + During the validation phase of a configuration run, a `No such object` error may occur for the Notebook and Viewscreen services. This error can be ignored as the services should still correctly start. + - | + If the root site administrator is locked out of the Management Console after failed login attempts, the account does not unlock automatically after the defined lockout time. Someone with administrative SSH access to the instance must unlock the account using the administrative shell. See [AUTOTITLE](/admin/administering-your-instance/administering-your-instance-from-the-web-ui/troubleshooting-access-to-the-management-console#unlocking-the-root-site-administrator-account). + - | + On an instance with the HTTP `X-Forwarded-For` header configured for use behind a load balancer, all client IP addresses in the instance's audit log erroneously appear as 127.0.0.1. + - | + {% data reusables.release-notes.large-adoc-files-issue %} + - | + Admin stats REST API endpoints may timeout on appliances with many users or repositories. Retrying the request until data is returned is advised. + - | + When following the steps for [Replacing the primary MySQL node](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-the-primary-mysql-node), step 14 (running `ghe-cluster-config-apply`) might fail with errors. If this occurs, re-running `ghe-cluster-config-apply` is expected to succeed. + - | + Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps. + - | + {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %} + - | + When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a nightly scheduled job. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`. + - | + An organization-level code scanning configuration page is displayed on instances that do not use GitHub Advanced Security or code scanning. + - | + When enabling automatic update checks for the first time in the Management Console, the status is not dynamically reflected until the "Updates" page is reloaded. + - | + When restoring from a backup snapshot, a large number of `mapper_parsing_exception` errors may be displayed. + - | + When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration. + - | + Admins setting up cluster high availability (HA) may encounter a spokes error when running `ghe-cluster-repl-status` if a new organization and repositories are created before using the `ghe-cluster-repl-bootstrap` command. To avoid this issue, complete the cluster HA setup with `ghe-cluster-repl-bootstrap` before creating new organizations and repositories. + - | + In a cluster, the host running restore requires access the storage nodes via their private IPs. + - | + On an instance hosted on Azure, commenting on an issue via email means the comment is not added to the issue. + - | + After a restore, existing outside collaborators cannot be added to repositories in a new organization. This issue can be resolved by running `/usr/local/share/enterprise/ghe-es-search-repair` on the appliance. + - | + After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. + - | + Unexpected elements may appear in the UI on the repository overview page for locked repositories. + - | + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + - | + The setting to define private registries at the organization level for code scanning is only available if dependabot is also enabled for the instance. + - | + Custom NTP settings are removed during the upgrade process. + - | + When applying an enterprise security configuration to all repositories (for example, enabling secret scanning or code scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. diff --git a/data/release-notes/enterprise-server/3-19/6.yml b/data/release-notes/enterprise-server/3-19/6.yml new file mode 100644 index 000000000000..5c3b16d55cda --- /dev/null +++ b/data/release-notes/enterprise-server/3-19/6.yml @@ -0,0 +1,103 @@ +date: '2026-05-07' +sections: + features: + - | + Site administrators can use the Enterprise Live Migrations (ELM) service to migrate repositories from GitHub Enterprise Server to a data-resident enterprise on GHE.com. Live migrations carry less downtime for developers than other migration tools, because the source repository is only locked during the cutover phase. This feature is in public preview and subject to change. See [AUTOTITLE](/migrations/elm/about-live-migrations). + - | + To prevent Redis replication failures in clusters with high write volumes, administrators can configure Redis replication backlog size and client output buffer limits via `ghe-config`. Previously, these settings used fixed defaults that could cause replica disconnections when write throughput exceeded buffer limits, resulting in continuous full-resync loops. Changes take effect after running a configuration run. + - | + The capability to configure multiple data disks to host MySQL and repository data is now generally available. This applies to standalone, and high-availability topologies, and it is generally available in the latest patch versions of 3.17, 3.18, 3.19, and 3.20. See [AUTOTITLE](/admin/monitoring-and-managing-your-instance/multiple-data-disks/configuring-multiple-data-disks). + security_fixes: + - | + **HIGH**: An attacker could exploit a server-side request forgery (SSRF) vulnerability in the notebook viewer to access internal services by exploiting URL parser confusion between the validation layer and the HTTP request library. This attack required network access to the GHES instance with private mode disabled. The vulnerability was addressed by aligning URL parsing between the validation and request layers and adding explicit validation of URL scheme, port, and userinfo components. GitHub has requested CVE ID [CVE-2026-8034](https://www.cve.org/cverecord?id=CVE-2026-8034) for this vulnerability, which was reported via the [GitHub Bug Bounty program](https://bounty.github.com). + - | + **MEDIUM**: An attacker could steal Management Console credentials by injecting malicious HTML into the login page via a crafted URL. The `redirect_to` query parameter was not properly sanitized, allowing an attacker to embed a form element that captured credentials submitted on the page. To mitigate this issue, GitHub replaced the template engine with one that properly enforces HTML auto-escaping. GitHub has requested CVE ID [CVE-2026-8106](https://www.cve.org/cverecord?id=CVE-2026-8106) for this vulnerability, which was reported via the [GitHub Bug Bounty program](https://bounty.github.com). + - | + **MEDIUM**: An attacker could cause a denial of service on the instance by sending crafted requests with deeply nested JSON payloads to an unauthenticated API endpoint. To mitigate this issue, GitHub has added maximum size and depth validation to the stats endpoint. GitHub has requested CVE ID [CVE-2026-7541](https://www.cve.org/cverecord?id=CVE-2026-7541) for this vulnerability, which was reported via the [GitHub Bug Bounty](https://bounty.github.com/) program. + - | + **MEDIUM**: An attacker could create a local user account on a GitHub Enterprise Server instance configured with an external authentication provider, bypassing the identity provider entirely. The signup endpoint did not properly enforce the external authentication restriction, allowing account creation and session establishment without identity provider validation. The created account was limited to the default base permissions configured on the instance. GitHub has requested CVE ID [CVE-2026-6736](https://www.cve.org/cverecord?id=CVE-2026-6736) for this vulnerability. + - | + **LOW**: An attacker could discover the existence and URLs of private repositories by making unauthorized REST API requests to public repository issues with parent issues in private repositories. The REST API unconditionally included the `parent_issue_url` field in issue responses, exposing private repository names, owners, and issue numbers to unauthenticated users or users without access to the parent repository. This vulnerability was reported via the [GitHub Bug Bounty](https://bounty.github.com/) program. + bugs: + - | + Users experienced failures with token-based authentication after the authnd service started but could not bind its HTTP port, leaving the service running but unable to serve requests. + - | + Administrators who cancelled `ghe-live-migrations` (Ctrl+C or SIGTERM) during a live upgrade found that the CLI exited but the live-upgrade container continued running in the background. The container now stops gracefully when the command is interrupted. + - | + Administrators found that SSH settings for agents on cloud platforms (such as Googles guest agent) did not persist after upgrading GitHub Enterprise Server, requiring reconfiguration after each upgrade. These settings are now carried over between upgrades. + - | + On instances with high push activity, commits did not appear in pull requests for minutes to hours, webhooks were delayed, and pull request state appeared stale. The stream processor service ran as a single process per node and could not scale horizontally to handle message volume. + - | + When initially configuring GitHub Actions with OIDC authentication, the configuration failed with an error indicating that OIDC was not enabled. + - | + On instances configured for high availability, GitHub Actions settings could not be changed through the Management Console. + - | + On instances using Enterprise teams, background jobs for enterprise team organization reconciliation accumulated in the queue and repeatedly failed when organization teams or team mappings were deleted while reconciliation jobs were running. This caused elevated latency for other background jobs. + - | + On an instance with SAML authentication and GitHub Pages configured, users were redirected to the root of the instance instead of their intended destination after completing SAML authentication. + - | + When delegated dismissal for secret scanning was enabled, users could submit dismissal requests for already-closed secret scanning alerts. These requests could not be reviewed or resolved via the UI, leaving alerts in a "request pending" state. + - | + The metrics page for secret scanning and push protection on security overview failed to load with an encoding error when pagination cursors contained binary data that could not be converted from UTF-8 to ASCII. + - | + On instances where persistent commit signature verification was disabled, commit quarantine processing jobs were still queued and backed up background job queues. + - | + On the secret scanning alert page for a generic secret, a feedback banner linked to a survey that no longer exists. + - | + Site administrators saw an “Automatically request Copilot code review” branch protection rule on GitHub Enterprise Server, even though the setting was not intended to be available on GHES. + - | + When exporting bot-initiated issue events for migrations, bot users were not resolved to a valid URL. + - | + When delegated alert dismissal was enabled for secret scanning, users without reviewer permissions saw a "Reopen alert" button on closed secret scanning alerts. Clicking the button returned a "Not Found" error. + changes: + - | + The `ghe-cluster-hotpatch` command now supports the `--parallel` flag. This flag executes the rollover stage in parallel across all nodes in a cluster, saving a significant amount of time during upgrades of large clusters. + - | + To support phased upgrades for future versions of GitHub Enterprise Server, site administrators can now use the `--phase` flag with the `ghe-upgrade` command. + - | + To prevent collectd memory exhaustion and OOM kills caused by write queue growth, administrators can configure collectd write queue limits and memory caps via `ghe-config`. Previously, tuning these settings required manual edits to collectd.conf and systemd configuration files. Changes take effect after running a configuration apply. + known_issues: + - | + During an upgrade of GitHub Enterprise Server, custom firewall rules are removed. If you use custom firewall rules, you must reapply them after upgrading. + - | + During the validation phase of a configuration run, a `No such object` error may occur for the Notebook and Viewscreen services. This error can be ignored as the services should still correctly start. + - | + If the root site administrator is locked out of the Management Console after failed login attempts, the account does not unlock automatically after the defined lockout time. Someone with administrative SSH access to the instance must unlock the account using the administrative shell. For more information, see [Troubleshooting access to the Management Console](/admin/administering-your-instance/administering-your-instance-from-the-web-ui/troubleshooting-access-to-the-management-console#unlocking-the-root-site-administrator-account). + - | + {% data reusables.release-notes.large-adoc-files-issue %} + - | + Admin stats REST API endpoints may timeout on appliances with many users or repositories. Retrying the request until data is returned is advised. + - | + When following the steps for [Replacing the primary MySQL node](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-the-primary-mysql-node), step 14 (running `ghe-cluster-config-apply`) might fail with errors. If this occurs, re-running `ghe-cluster-config-apply` is expected to succeed. + - | + Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps. + - | + {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %} + - | + When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a nightly scheduled job. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`. + - | + When enabling automatic update checks for the first time in the Management Console, the status is not dynamically reflected until the "Updates" page is reloaded. + - | + When restoring from a backup snapshot, a large number of `mapper_parsing_exception` errors may be displayed. + - | + When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration. + - | + Admins setting up cluster high availability (HA) may encounter a spokes error when running `ghe-cluster-repl-status` if a new organization and repositories are created before using the `ghe-cluster-repl-bootstrap` command. To avoid this issue, complete the cluster HA setup with `ghe-cluster-repl-bootstrap` before creating new organizations and repositories. + - | + In a cluster, the host running restore requires access the storage nodes via their private IPs. + - | + On an instance hosted on Azure, commenting on an issue via email meant the comment was not added to the issue. + - | + After a restore, existing outside collaborators cannot be added to repositories in a new organization. This issue can be resolved by running `/usr/local/share/enterprise/ghe-es-search-repair` on the appliance. + - | + After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. + - | + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + - | + The setting to define private registries at the organization level for code scanning is only available if dependabot is also enabled for the instance. + - | + Upgrading or hotpatching to 3.19.1 may fail on nodes that have been continuously upgraded from versions older than 2021 (i.e. 2.17). If this issue occurs, you will see log entries prefixed with `invalid secret` in ghe-config.log. If you are running nodes from these older versions, it is recommended not to upgrade to 3.19.1. + - | + In patch 3.19.1, we identified an issue in the Management Console where the Backups (Preview) and Updates tabs may fail to open and instead return an Internal Server Error. We recommend using the command line interface (CLI) for backups and updates until an updated patch is released. + - | + When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. diff --git a/data/release-notes/enterprise-server/3-20/2.yml b/data/release-notes/enterprise-server/3-20/2.yml new file mode 100644 index 000000000000..0fa022d36d9c --- /dev/null +++ b/data/release-notes/enterprise-server/3-20/2.yml @@ -0,0 +1,95 @@ +date: '2026-05-07' +sections: + features: + - | + Site administrators can use the Enterprise Live Migrations (ELM) service to migrate repositories from GitHub Enterprise Server to a data-resident enterprise on GHE.com. Live migrations carry less downtime for developers than other migration tools, because the source repository is only locked during the cutover phase. This feature is in public preview and subject to change. See [AUTOTITLE](/migrations/elm/about-live-migrations). + - | + To prevent Redis replication failures in clusters with high write volumes, administrators can configure Redis replication backlog size and client output buffer limits via `ghe-config`. Previously, these settings used fixed defaults that could cause replica disconnections when write throughput exceeded buffer limits, resulting in continuous full-resync loops. Changes take effect after running a configuration run. + - | + The capability to configure multiple data disks to host MySQL and repository data is now generally available. This applies to standalone, and high-availability topologies, and it is generally available in the latest patch versions of 3.17, 3.18, 3.19, and 3.20. See [AUTOTITLE](/admin/monitoring-and-managing-your-instance/multiple-data-disks/configuring-multiple-data-disks). + - | + You can configure a dedicated disk for log storage, mounted at `/var/log` and configured as an LVM volume, to isolate logs from the root disk. This capability applies only to standalone and high-availability topologies, not to cluster topologies. This is now generally available in the latest patch version of 3.20. See [AUTOTITLE](/admin/monitoring-and-managing-your-instance/multiple-data-disks/configuring-multiple-data-disks). + security_fixes: + - | + **HIGH**: An attacker could exploit a server-side request forgery (SSRF) vulnerability in the notebook viewer to access internal services by exploiting URL parser confusion between the validation layer and the HTTP request library. This attack required network access to the GHES instance with private mode disabled. The vulnerability was addressed by aligning URL parsing between the validation and request layers and adding explicit validation of URL scheme, port, and userinfo components. GitHub has requested CVE ID [CVE-2026-8034](https://www.cve.org/cverecord?id=CVE-2026-8034) for this vulnerability, which was reported via the [GitHub Bug Bounty program](https://bounty.github.com). + - | + **MEDIUM**: An attacker could steal Management Console credentials by injecting malicious HTML into the login page via a crafted URL. The `redirect_to` query parameter was not properly sanitized, allowing an attacker to embed a form element that captured credentials submitted on the page. To mitigate this issue, GitHub replaced the template engine with one that properly enforces HTML auto-escaping. GitHub has requested CVE ID [CVE-2026-8106](https://www.cve.org/cverecord?id=CVE-2026-8106) for this vulnerability, which was reported via the [GitHub Bug Bounty program](https://bounty.github.com). + - | + **MEDIUM**: An attacker could cause a denial of service on the instance by sending crafted requests with deeply nested JSON payloads to an unauthenticated API endpoint. To mitigate this issue, GitHub has added maximum size and depth validation to the stats endpoint. GitHub has requested CVE ID [CVE-2026-7541](https://www.cve.org/cverecord?id=CVE-2026-7541) for this vulnerability, which was reported via the [GitHub Bug Bounty](https://bounty.github.com/) program. + - | + **MEDIUM**: An attacker could create a local user account on a GitHub Enterprise Server instance configured with an external authentication provider, bypassing the identity provider entirely. The signup endpoint did not properly enforce the external authentication restriction, allowing account creation and session establishment without identity provider validation. The created account was limited to the default base permissions configured on the instance. GitHub has requested CVE ID [CVE-2026-6736](https://www.cve.org/cverecord?id=CVE-2026-6736) for this vulnerability. + - | + **LOW**: An attacker could discover the existence and URLs of private repositories by making unauthorized REST API requests to public repository issues with parent issues in private repositories. The REST API unconditionally included the `parent_issue_url` field in issue responses, exposing private repository names, owners, and issue numbers to unauthenticated users or users without access to the parent repository. This vulnerability was reported via the [GitHub Bug Bounty](https://bounty.github.com/) program. + bugs: + - | + Users experienced failures with token-based authentication after the authnd service started but could not bind its HTTP port, leaving the service running but unable to serve requests. + - | + Administrators who cancelled `ghe-live-migrations` (Ctrl+C or SIGTERM) during a live upgrade found that the CLI exited but the live-upgrade container continued running in the background. The container now stops gracefully when the command is interrupted. + - | + Administrators found that SSH settings for agents on cloud platforms (such as Googles guest agent) did not persist after upgrading GitHub Enterprise Server, requiring reconfiguration after each upgrade. These settings are now carried over between upgrades. + - | + On instances with high push activity, commits did not appear in pull requests for minutes to hours, webhooks were delayed, and pull request state appeared stale. The stream processor service ran as a single process per node and could not scale horizontally to handle message volume. + - | + When initially configuring GitHub Actions with OIDC authentication, the configuration failed with an error indicating that OIDC was not enabled. + - | + On instances configured for high availability, GitHub Actions settings could not be changed through the Management Console. + - | + On the secret scanning alert page for a generic secret, a feedback banner linked to a survey that no longer exists. + - | + On instances using Enterprise teams, background jobs for enterprise team organization reconciliation accumulated in the queue and repeatedly failed when organization teams or team mappings were deleted while reconciliation jobs were running. This caused elevated latency for other background jobs. + - | + On an instance with SAML authentication and GitHub Pages configured, users were redirected to the root of the instance instead of their intended destination after completing SAML authentication. + - | + When delegated dismissal for secret scanning was enabled, users could submit dismissal requests for already-closed secret scanning alerts. These requests could not be reviewed or resolved via the UI, leaving alerts in a "request pending" state. + - | + The metrics page for secret scanning and push protection on security overview failed to load with an encoding error when pagination cursors contained binary data that could not be converted from UTF-8 to ASCII. + - | + On instances where persistent commit signature verification was disabled, commit quarantine processing jobs were still queued and backed up background job queues. + - | + When exporting bot-initiated issue events for migrations, bot users were not resolved to a valid URL. + - | + When delegated alert dismissal was enabled for secret scanning, users without reviewer permissions saw a "Reopen alert" button on closed secret scanning alerts. Clicking the button returned a "Not Found" error. + - | + Secret scannings Pulumi token validator encountered errors when validating some Pulumi tokens. + changes: + - | + The `ghe-cluster-hotpatch` command now supports the `--parallel` flag. This flag executes the rollover stage in parallel across all nodes in a cluster, saving a significant amount of time during upgrades of large clusters. + - | + To support phased upgrades for future versions of GitHub Enterprise Server, site administrators can now use the `--phase` flag with the `ghe-upgrade` command. + - | + To prevent collectd memory exhaustion and OOM kills caused by write queue growth, administrators can configure collectd write queue limits and memory caps via `ghe-config`. Previously, tuning these settings required manual edits to collectd.conf and systemd configuration files. Changes take effect after running a configuration apply. + known_issues: + - | + During an upgrade of GitHub Enterprise Server, custom firewall rules are removed. If you use custom firewall rules, you must reapply them after upgrading. + - | + During the validation phase of a configuration run, a `No such object` error may occur for the Notebook and Viewscreen services. This error can be ignored as the services should still correctly start. + - | + If the root site administrator is locked out of the Management Console after failed login attempts, the account does not unlock automatically after the defined lockout time. Someone with administrative SSH access to the instance must unlock the account using the administrative shell. See [AUTOTITLE](/admin/administering-your-instance/administering-your-instance-from-the-web-ui/troubleshooting-access-to-the-management-console#unlocking-the-root-site-administrator-account). + - | + {% data reusables.release-notes.large-adoc-files-issue %} + - | + Admin stats REST API endpoints may timeout on appliances with many users or repositories. Retrying the request until data is returned is advised. + - | + When following the steps for [Replacing the primary MySQL node](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-the-primary-mysql-node), step 14 (running `ghe-cluster-config-apply`) might fail with errors. If this occurs, re-running `ghe-cluster-config-apply` is expected to succeed. + - | + Running a config apply as part of the steps for [Replacing a node in an emergency](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/replacing-a-cluster-node#replacing-a-node-in-an-emergency) may fail with errors if the node being replaced is still reachable. If this occurs, shutdown the node and repeat the steps. + - | + When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a nightly scheduled job. It can also be forced by running `/usr/local/share/enterprise/ghe-es-search-repair`. + - | + When initializing a new GHES cluster, nodes with the `consul-server` role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration. + - | + Admins setting up cluster high availability (HA) may encounter a spokes error when running `ghe-cluster-repl-status` if a new organization and repositories are created before using the `ghe-cluster-repl-bootstrap` command. To avoid this issue, complete the cluster HA setup with `ghe-cluster-repl-bootstrap` before creating new organizations and repositories. + - | + In a cluster, the host running restore requires access the storage nodes via their private IPs. + - | + On an instance hosted on Azure, commenting on an issue via email means the comment is not added to the issue. + - | + After a restore, existing outside collaborators cannot be added to repositories in a new organization. This issue can be resolved by running `/usr/local/share/enterprise/ghe-es-search-repair` on the appliance. + - | + After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. + - | + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + - | + When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. + - | + On instances with multiple Git storage nodes in a voting configuration, including cluster and geo-replication high availability topologies, upgrading may fail to correctly install Actions that ship with the new version. In some cases, previous versions of these Actions remain on the instance. To resolve this issue, run the following commands on the primary node: `ghe-config --unset 'app.actions.actions-repos-sha1sum'`, `ghe-config-apply`, and `/usr/local/share/enterprise/ghe-run-init-actions-graph`. diff --git a/data/reusables/elm/concurrent-migrations.md b/data/reusables/elm/concurrent-migrations.md new file mode 100644 index 000000000000..08a87c996032 --- /dev/null +++ b/data/reusables/elm/concurrent-migrations.md @@ -0,0 +1 @@ +up to **10** concurrent repository migrations from a single {% data variables.product.prodname_ghe_server %} instance, and **20** concurrent migrations per destination enterprise. \ No newline at end of file diff --git a/data/reusables/elm/ghe-pat-description.md b/data/reusables/elm/ghe-pat-description.md new file mode 100644 index 000000000000..2d20f0ca17ab --- /dev/null +++ b/data/reusables/elm/ghe-pat-description.md @@ -0,0 +1 @@ +The {% data variables.product.pat_v1 %} for {% data variables.enterprise.data_residency_site %} diff --git a/data/reusables/elm/ghe-url-description.md b/data/reusables/elm/ghe-url-description.md new file mode 100644 index 000000000000..fc72dd9769e3 --- /dev/null +++ b/data/reusables/elm/ghe-url-description.md @@ -0,0 +1 @@ +The API URL for your destination enterprise (for example: `https://api.{% data variables.enterprise.data_residency_example_domain %}`). Do **not** include a trailing slash at the end of the URL. diff --git a/data/reusables/elm/ghes-version-requirement.md b/data/reusables/elm/ghes-version-requirement.md new file mode 100644 index 000000000000..1b0c286995f3 --- /dev/null +++ b/data/reusables/elm/ghes-version-requirement.md @@ -0,0 +1,7 @@ + + + +To use ELM, upgrade to a supported {% data variables.product.prodname_ghe_server %} patch release. + +Minimum versions: **3.20.2**, **3.19.6**, **3.18.9**, **3.17.15**. + \ No newline at end of file diff --git a/data/reusables/elm/git-activity.md b/data/reusables/elm/git-activity.md new file mode 100644 index 000000000000..020c2b539ef0 --- /dev/null +++ b/data/reusables/elm/git-activity.md @@ -0,0 +1 @@ +Authorship for Git commits is not associated with mannequins and cannot be attributed to {% data variables.product.prodname_dotcom %} users by reclaiming mannequins. Instead, commit authorship is attributed to user accounts on {% data variables.product.github %} based on the email address that was used to author the commit in Git. diff --git a/data/reusables/elm/hmac-key-value.md b/data/reusables/elm/hmac-key-value.md new file mode 100644 index 000000000000..976ff0198dfd --- /dev/null +++ b/data/reusables/elm/hmac-key-value.md @@ -0,0 +1 @@ +$(ghe-config secrets.elm-exporter.elm-exporter-hmac-keys) \ No newline at end of file diff --git a/data/reusables/elm/localhost-value.md b/data/reusables/elm/localhost-value.md new file mode 100644 index 000000000000..f342748276e3 --- /dev/null +++ b/data/reusables/elm/localhost-value.md @@ -0,0 +1 @@ +http://localhost:1738 \ No newline at end of file diff --git a/data/reusables/elm/locked-repo.md b/data/reusables/elm/locked-repo.md new file mode 100644 index 000000000000..7cd9ef640042 --- /dev/null +++ b/data/reusables/elm/locked-repo.md @@ -0,0 +1,5 @@ +If a cutover fails partway through, the source repository may remain locked or archived. This prevents developers from pushing to the source while the destination may still be incomplete. + +To unlock the source repository, a site administrator must unlock it from the {% data variables.product.prodname_ghe_server %} {% data variables.enterprise.management_console %}. + +After the source is unlocked, you can either retry cutover using `elm migration cutover-to-destination --migration-id MIGRATION-ID`, or abort the migration with `elm migration cancel --migration-id MIGRATION-ID` and start a new migration when you're ready. diff --git a/data/reusables/elm/preview-note.md b/data/reusables/elm/preview-note.md new file mode 100644 index 000000000000..62330c7645e6 --- /dev/null +++ b/data/reusables/elm/preview-note.md @@ -0,0 +1 @@ +>[!NOTE] {% data variables.product.prodname_elm %} is in {% data variables.release-phases.public_preview %} and subject to change. diff --git a/data/reusables/elm/reclaim-mannequins-in-browser.md b/data/reusables/elm/reclaim-mannequins-in-browser.md new file mode 100644 index 000000000000..53178a679809 --- /dev/null +++ b/data/reusables/elm/reclaim-mannequins-in-browser.md @@ -0,0 +1,11 @@ +{% data reusables.profile.access_org %} +{% data reusables.profile.org_settings %} +{% data reusables.enterprise-migration-tool.import-export-tab %} +1. To the right of the mannequin you want to reclaim, click **Reattribute**. +1. In the search field, type the username of the organization member you want to attribute the mannequin's contributions to, then click the member. + + > [!NOTE] + > You can only send attribution invitations to user accounts that are already members of the organization. + +1. Click **Invite**. +{% data reusables.enterprise-migration-tool.mannequin-reclaim-must-accept %} diff --git a/data/reusables/enterprise-migration-tool/about-mannequins.md b/data/reusables/enterprise-migration-tool/about-mannequins.md index 715dc29ded26..2a7debae2e61 100644 --- a/data/reusables/enterprise-migration-tool/about-mannequins.md +++ b/data/reusables/enterprise-migration-tool/about-mannequins.md @@ -1 +1 @@ -After you run a migration with {% data variables.product.prodname_importer_proper_name %}, all user activity in the migrated repository (except Git commits) is attributed to placeholder identities called mannequins. +After you run a migration with {% data variables.product.prodname_importer_proper_name %} or {% data variables.product.prodname_elm %}, all user activity in the migrated repository (except Git commits) is attributed to placeholder identities called mannequins. diff --git a/data/reusables/enterprise-migration-tool/repository-migrations-bypass.md b/data/reusables/enterprise-migration-tool/repository-migrations-bypass.md index 4b9019b88192..6312b6f045e9 100644 --- a/data/reusables/enterprise-migration-tool/repository-migrations-bypass.md +++ b/data/reusables/enterprise-migration-tool/repository-migrations-bypass.md @@ -6,4 +6,4 @@ To configure the bypass: 1. In the "Bypass list" section, click **Add bypass**. 1. Select **Repository migrations**. -For more information, see [AUTOTITLE](/organizations/managing-organization-settings/creating-rulesets-for-repositories-in-your-organization#granting-bypass-permissions-for-your-branch-or-tag-ruleset) and [AUTOTITLE](/migrations/troubleshooting/setting-ruleset-bypasses-for-repository-migrations). +For more information, see [AUTOTITLE](/organizations/managing-organization-settings/creating-rulesets-for-repositories-in-your-organization#granting-bypass-permissions-for-your-branch-or-tag-ruleset) and [AUTOTITLE](/enterprise-cloud@latest/migrations/troubleshooting/setting-ruleset-bypasses-for-repository-migrations). diff --git a/data/reusables/enterprise-migration-tool/validate-migration-logs.md b/data/reusables/enterprise-migration-tool/validate-migration-logs.md index 3907250870fa..391319b15afa 100644 --- a/data/reusables/enterprise-migration-tool/validate-migration-logs.md +++ b/data/reusables/enterprise-migration-tool/validate-migration-logs.md @@ -1,3 +1,3 @@ -When your migration is complete, we recommend reviewing your migration log. For more information, see [AUTOTITLE](/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/accessing-your-migration-logs-for-github-enterprise-importer). If your source repository contained rulesets and you're being blocked by them, see [AUTOTITLE](/migrations/troubleshooting/setting-ruleset-bypasses-for-repository-migrations). +When your migration is complete, we recommend reviewing your migration log. For more information, see [AUTOTITLE](/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/accessing-your-migration-logs-for-github-enterprise-importer). If your source repository contained rulesets and you're being blocked by them, see [AUTOTITLE](/enterprise-cloud@latest/migrations/troubleshooting/setting-ruleset-bypasses-for-repository-migrations). We recommend that you review your migrated repositories for a soundness check. diff --git a/data/variables/product.yml b/data/variables/product.yml index b0f41e1461f9..1ec5a748f3c2 100644 --- a/data/variables/product.yml +++ b/data/variables/product.yml @@ -53,6 +53,10 @@ prodname_bbs2gh_cli: BBS2GH extension of the GitHub CLI prodname_bbs2gh_cli_short: BBS2GH extension prodname_ghos: GitHub-owned blob storage +## Enterprise Live Migrations +prodname_elm: Enterprise Live Migrations +prodname_elm_short: ELM + # GitHub Education prodname_education: 'GitHub Education' prodname_education_community: 'Education Community'