Commit 228d195a authored by GitLab Bot's avatar GitLab Bot

Automatic merge of gitlab-org/gitlab-ce master

parents 27a207fc c16619c5
......@@ -112,9 +112,7 @@ export default {
const truncatedContentSha = _.escape(truncateSha(this.diffFile.content_sha));
return sprintf(
s__('MergeRequests|View file @ %{commitId}'),
{
commitId: `<span class="commit-sha">${truncatedContentSha}</span>`,
},
{ commitId: truncatedContentSha },
false,
);
},
......
......@@ -110,7 +110,7 @@ enabled for all new projects.
To start a migration, enable Hashed Storage for new projects:
1. Go to **Admin > Settings** and expand the **Repository Storage** section.
1. Go to **Admin > Settings > Repository** and expand the **Repository Storage** section.
2. Select the **Use hashed storage paths for newly created and renamed projects** checkbox.
Check if the change breaks any existing integration you may have that
......@@ -138,7 +138,7 @@ source-based installation.
Similar to the migration, to disable Hashed Storage for new
projects:
1. Go to **Admin > Settings** and expand the **Repository Storage** section.
1. Go to **Admin > Settings > Repository** and expand the **Repository Storage** section.
2. Uncheck the **Use hashed storage paths for newly created and renamed projects** checkbox.
To schedule a complete rollback, see the
......
......@@ -23,11 +23,28 @@ There is also the option of [connecting your external repository to get CI/CD be
## Migrating from self-hosted GitLab to GitLab.com
You can copy your repos by changing the remote and pushing to the new server,
but issues and merge requests can't be imported.
If you only need to migrate git repos, you can [import each project by URL](repo_by_url.md), but issues and merge requests can't be imported.
If you want to retain all metadata like issues and merge requests, you can use
the [import/export feature](../settings/import_export.md).
the [import/export feature](../settings/import_export.md) to export projects from self-hosted GitLab and import those projects into GitLab.com.
NOTE: **Note:**
This approach assumes all users from the self-hosted instance have already been migrated.
If the users haven't been migrated yet, the user conducting the import
will take the place of all references to the missing user(s).
If you need to migrate all data over, you can leverage our [api](../../../api/README.md) to migrate from self-hosted to GitLab.com.
The order of assets to migrate from a self-hosted instance to GitLab is the following:
1. [Users](../../../api/users.md)
1. [Groups](../../../api/groups.md)
1. [Projects](../../../api/projects.md)
1. [Project variables](../../../api/project_level_variables.md)
Keep in mind the limitations of the [import/export feature](../settings/import_export.md#exported-contents).
You will still need to migrate your Container Registry over a series of
Docker pulls and pushes and re-run any CI pipelines to retrieve any build artifacts.
## Migrating between two self-hosted GitLab instances
......@@ -35,3 +52,6 @@ The best method for migrating a project from one GitLab instance to another,
perhaps from an old server to a new server for example, is to
[back up the project](../../../raketasks/backup_restore.md),
then restore it on the new server.
In the event of merging two GitLab instances together (for example, both instances have existing data on them and one can't be wiped),
refer to the instructions in [Migrating from self-hosted GitLab to GitLab.com](#migrating-from-self-hosted-gitlab-to-gitlabcom).
......@@ -611,6 +611,9 @@ describe('diff_file_header', () => {
vm = mountComponentWithStore(Component, { props, store });
expect(viewFileButton().getAttribute('href')).toBe('view-path');
expect(viewFileButton().getAttribute('data-original-title')).toEqual(
`View file @ ${props.diffFile.content_sha.substr(0, 8)}`,
);
});
it('should not render external url view link if diff file has no external url', () => {
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment