Commit 0ca96da5 authored by Marcel Amirault's avatar Marcel Amirault

Merge branch 'eread/revamp-project-import-export-content' into 'master'

Improve project import/export content

See merge request gitlab-org/gitlab!24130
parents 843cfce7 1c5e3690
# Project import/export administration **(CORE ONLY)** # Project import/export administration **(CORE ONLY)**
>**Note:** > - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/3050) in GitLab 8.9.
> > - From GitLab 11.3, import/export can use object storage automatically.
> - [Introduced][ce-3050] in GitLab 8.9.
> - Importing will not be possible if the import instance version is lower See also:
> than that of the exporter.
> - For existing installations, the project import option has to be enabled in - [Project import/export documentation](../../user/project/settings/import_export.md).
> application settings (`/admin/application_settings`) under 'Import sources'. - [Project import/export API](../../api/project_import_export.md).
> - The exports are stored in a temporary [shared directory][tmp] and are deleted
> every 24 hours by a specific worker. The GitLab import/export version can be checked by using the following command:
> - ImportExport can use object storage automatically starting from GitLab 11.3
The GitLab Import/Export version can be checked by using:
```shell ```shell
# Omnibus installations # Omnibus installations
...@@ -21,7 +18,7 @@ sudo gitlab-rake gitlab:import_export:version ...@@ -21,7 +18,7 @@ sudo gitlab-rake gitlab:import_export:version
bundle exec rake gitlab:import_export:version RAILS_ENV=production bundle exec rake gitlab:import_export:version RAILS_ENV=production
``` ```
The current list of DB tables that will get exported can be listed by using: The current list of DB tables that will be exported can be listed by using the following command:
```shell ```shell
# Omnibus installations # Omnibus installations
...@@ -31,5 +28,13 @@ sudo gitlab-rake gitlab:import_export:data ...@@ -31,5 +28,13 @@ sudo gitlab-rake gitlab:import_export:data
bundle exec rake gitlab:import_export:data RAILS_ENV=production bundle exec rake gitlab:import_export:data RAILS_ENV=production
``` ```
[ce-3050]: https://gitlab.com/gitlab-org/gitlab-foss/issues/3050 ## Important notes
[tmp]: ../../development/shared_files.md
Note the following:
- Importing is not possible if the version of the import instance is older than that of the exporter.
- The project import option must be enabled in
application settings (`/admin/application_settings`) under **Import sources**, which is available
under **{admin}** **Admin Area >** **{settings}** **Settings > Visibility and access controls**.
- The exports are stored in a temporary [shared directory](../../development/shared_files.md)
and are deleted every 24 hours by a specific worker.
# Project import/export API # Project import/export API
> [Introduced][ce-41899] in GitLab 10.6. > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/41899) in GitLab 10.6.
See also the [project import/export documentation](../user/project/settings/import_export.md). See also:
- [Project import/export documentation](../user/project/settings/import_export.md).
- [Project import/export administration rake tasks](../administration/raketasks/project_import_export.md). **(CORE ONLY)**
## Schedule an export ## Schedule an export
Start a new export. Start a new export.
The endpoint also accepts an `upload` param. This param is a hash that contains The endpoint also accepts an `upload` parameter. This parameter is a hash that contains
all the necessary information to upload the exported project to a web server or all the necessary information to upload the exported project to a web server or
to any S3-compatible platform. At the moment we only support binary to any S3-compatible platform. At the moment we only support binary
data file uploads to the final server. data file uploads to the final server.
If the `upload` params is present, `upload[url]` param is required. From GitLab 10.7, the `upload[url]` parameter is required if the `upload` parameter is present.
(**Note:** This feature was introduced in GitLab 10.7)
```text ```text
POST /projects/:id/export POST /projects/:id/export
...@@ -56,8 +58,14 @@ GET /projects/:id/export ...@@ -56,8 +58,14 @@ GET /projects/:id/export
curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/1/export curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/1/export
``` ```
Status can be one of `none`, `started`, `after_export_action` or `finished`. The Status can be one of:
`after_export_action` state represents that the export process has been completed successfully and
- `none`
- `started`
- `after_export_action`
- `finished`
The `after_export_action` state represents that the export process has been completed successfully and
the platform is performing some actions on the resulted file. For example, sending the platform is performing some actions on the resulted file. For example, sending
an email notifying the user to download the file, uploading the exported file an email notifying the user to download the file, uploading the exported file
to a web server, etc. to a web server, etc.
...@@ -178,7 +186,13 @@ GET /projects/:id/import ...@@ -178,7 +186,13 @@ GET /projects/:id/import
curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/1/import curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/1/import
``` ```
Status can be one of `none`, `scheduled`, `failed`, `started`, or `finished`. Status can be one of:
- `none`
- `scheduled`
- `failed`
- `started`
- `finished`
If the status is `failed`, it will include the import error message under `import_error`. If the status is `failed`, it will include the import error message under `import_error`.
...@@ -194,5 +208,3 @@ If the status is `failed`, it will include the import error message under `impor ...@@ -194,5 +208,3 @@ If the status is `failed`, it will include the import error message under `impor
"import_status": "started" "import_status": "started"
} }
``` ```
[ce-41899]: https://gitlab.com/gitlab-org/gitlab-foss/issues/41899
# Project import/export # Project import/export
>**Notes:**
>
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/3050) in GitLab 8.9. > - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/3050) in GitLab 8.9.
> - Importing will not be possible if the import instance version differs from > - From GitLab 10.0, administrators can disable the project export option on the GitLab instance.
> that of the exporter.
> - For GitLab admins, please read through Existing projects running on any GitLab instance or GitLab.com can be exported with all their related
> [Project import/export administration](../../../administration/raketasks/project_import_export.md). data and be moved into a new GitLab instance.
> - For existing installations, the project import option has to be enabled in
> application settings (`/admin/application_settings`) under 'Import sources'. See also:
> Ask your administrator if you don't see the **GitLab export** button when
> creating a new project. - [Project import/export API](../../../api/project_import_export.md).
> - Starting with GitLab 10.0, administrators can disable the project export option - [Project import/export administration rake tasks](../../../administration/raketasks/project_import_export.md). **(CORE ONLY)**
> on the GitLab instance in application settings (`/admin/application_settings`)
> under 'Visibility and Access Controls'. ## Important notes
> - You can find some useful raketasks if you are an administrator in the
> [import_export](../../../administration/raketasks/project_import_export.md) raketask. Note the following:
> - The exports are stored in a temporary [shared directory](../../../development/shared_files.md)
> and are deleted every 24 hours by a specific worker. - Importing is not possible if the import instance version differs from
> - Group members will get exported as project members, as long as the user has that of the exporter.
> maintainer or admin access to the group where the exported project lives. An admin - The project import option must be enabled in
> in the import side is required to map the users, based on email or username. application settings (`/admin/application_settings`) under under **Import sources**, which is
> Otherwise, a supplementary comment is left to mention the original author and available under **{admin}** **Admin Area >** **{settings}** **Settings > Visibility and access controls**.
> the MRs, notes or issues will be owned by the importer. Ask your administrator if you don't see the **GitLab export** button when
> - Project members with owner access will get imported as maintainers. creating a new project.
> - Control project Import/Export with the [API](../../../api/project_import_export.md). - The exports are stored in a temporary [shared directory](../../../development/shared_files.md)
> - If an imported project contains merge requests originated from forks, and are deleted every 24 hours by a specific worker.
> then new branches associated with such merge requests will be created - Group members are exported as project members, as long as the user has
> within a project during the import/export. Thus, the number of branches maintainer or admin access to the group where the exported project lives. An admin
> in the exported project could be bigger than in the original project. in the import side is required to map the users, based on email or username.
Otherwise, a supplementary comment is left to mention the original author and
Existing projects running on any GitLab instance or GitLab.com can be exported the MRs, notes, or issues will be owned by the importer.
with all their related data and be moved into a new GitLab instance. - Project members with owner access will be imported as maintainers.
- If an imported project contains merge requests originating from forks,
then new branches associated with such merge requests will be created
within a project during the import/export. Thus, the number of branches
in the exported project could be bigger than in the original project.
## Version history ## Version history
The following table lists updates to Import/Export:
| GitLab version | Import/Export version | | GitLab version | Import/Export version |
| ---------------- | --------------------- | | ---------------- | --------------------- |
| 11.1 to current | 0.2.4 | | 11.1 to current | 0.2.4 |
...@@ -52,9 +56,8 @@ with all their related data and be moved into a new GitLab instance. ...@@ -52,9 +56,8 @@ with all their related data and be moved into a new GitLab instance.
| 8.9.5 | 0.1.1 | | 8.9.5 | 0.1.1 |
| 8.9.0 | 0.1.0 | | 8.9.0 | 0.1.0 |
> The table reflects what GitLab version we updated the Import/Export version at. For example, 8.10.3 and 8.11 will have the same Import/Export version (0.1.3)
> For instance, 8.10.3 and 8.11 will have the same Import/Export version (0.1.3) and the exports between them will be compatible.
> and the exports between them will be compatible.
## Exported contents ## Exported contents
...@@ -88,7 +91,7 @@ For more details on the specific data persisted in a project export, see the ...@@ -88,7 +91,7 @@ For more details on the specific data persisted in a project export, see the
1. Go to your project's homepage. 1. Go to your project's homepage.
1. Click **Settings** in the sidebar. 1. Click **{settings}** **Settings** in the sidebar.
1. Scroll down to find the **Export project** button: 1. Scroll down to find the **Export project** button:
......
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