Exporting
Before you start your export
Always carefully review the migration prerequisites before starting the export process.
Decide which project or repositories you want to migrate.
You will require project keys and repository slugs, which you can get from the URL of the repository.
Visiting an URL for a repository
The format is https://bitbucket.example.com/projects/PROJECT/repos/repository, where PROJECT is the project key and repository is the repository slug.
Previewing the export
Previewing allows you to experiment with the export request and returns a list of repositories that would be included with a given request.
You can perform a preview using the below command:
curl -u <adminusername> -s -n -X POST -H 'Content-type: application/json' -d '{"repositoriesRequest":{"includes":[{"projectKey":"*","slug":"*"}]}}' http://localhost:7990/rest/api/1.0/migration/exports/preview | jq .
The following request values are required for preview (REST Documentation):
| Description | Value |
|---|---|
| URL | /rest/api/1.0/migration/exports/preview |
| HTTP verb | POST |
| HTTP header | Content-type: application/json |
| Authentication | Basic |
To preview all repositories:
{
"repositoriesRequest": {
"includes": [
{
"projectKey":"*",
"slug":"*"
}
]
}
}To preview one full project and a specific repository:
{
"repositoriesRequest": {
"includes": [
{
"projectKey":"PROJECTKEY",
"slug":"*"
},
{
"projectKey":"PROJECTKEY2",
"slug":"repository-slug"
}
]
}
}If needed, you can specify the project key and slug pair as many times as necessary.
As soon as you select one repository of a fork hierarchy, then every repository of that fork hierarchy will be exported, including personal forks and origins of the repository.
Performing the export
Once the export is started, an archive file will be written to disk containing all necessary Git data and database entities.
The archive file can be found after the migration is finished, in $BITBUCKET_SHARED_HOME/data/migration/export/Bitbucket_export_<Job ID>.tar
You can perform the export using the below command:
curl -u <adminusername> -s -n -X POST -H 'Content-type: application/json' -d '{"repositoriesRequest":{"includes":[{"projectKey":"*","slug":"*"}]}}' http://localhost:7990/rest/api/1.0/migration/exports | jq .The following values are required for export (REST Documentation):
| Description | Value |
|---|---|
| URL | /rest/api/1.0/migration/exports |
| HTTP verb | POST |
| HTTP header | Content-type: application/json |
| Authentication | Basic |
Note: exactly the same request body as with previewing the export can be used.
To export all repositories:
{
"repositoriesRequest": {
"includes": [
{
"projectKey":"*",
"slug":"*"
}
]
}
}To export one full project and a specific repository:
{
"repositoriesRequest": {
"includes": [
{
"projectKey":"PROJECTKEY",
"slug":"*"
},
{
"projectKey":"PROJECTKEY2",
"slug":"repository-slug"
}
]
}
}You can specify the projectKey and slug pair as many times as necessary.
As soon as you select one repository of a fork hierarchy, then every repository of that fork hierarchy will be exported, including personal forks and origins of the repository.
The response will contain the job ID, which is important to query the status of the job later.
During the export
You can query the following specific REST endpoint to see progress:
watch -n30 'curl -u <adminusername> -s -n -X GET http://localhost:7990/rest/api/1.0/migration/exports/<Job ID> | jq .'Replace <Job ID> with the "id" value that was returned from the request that started the export job.
The following values are required to query the progress (REST Documentation):
| Description | Value |
|---|---|
| URL | /rest/api/1.0/migration/exports/<Job ID> |
| HTTP verb | GET |
| Authentication | Basic |
After the export
On completion, the job state will change to COMPLETED and the export file can be found in $BITBUCKET_SHARED_HOME/data/migration/export/Bitbucket_export_<Job ID>.tar. If any errors occurred, the job state will change to ABORTED for fatal errors or FAILED.
To check for warnings or errors:
curl -u <adminusername> -s -n -X GET http://localhost:7990/rest/api/1.0/migration/exports/<Job ID>/messages | jq .Replace <Job ID> with the "id" value that was returned from the request that started the export job.
The following values are required to check for warnings or errors (REST Documentation):
| Description | Value |
|---|---|
| URL | /rest/api/1.0/migration/exports/<Job ID>/messages |
| HTTP verb | GET |
| Authentication | Basic |
Warning messages should be dealt with on a case-by-case basis, it generally means that some data was not exported but the archive can be used to import into another instance.
Error messages generally mean that the archive that was generated is not usable. Please see the troubleshooting section for more information.
Canceling the export
You may see a small delay between accepting the request and the actual job cancelation. In most cases, the delay will be inconsequential.
In the unlikely case of communication issues across a cluster, it may take a few seconds to cancel a job.
You should always actively query the job status to confirm that a job has been successfully canceled.
The export archive will remain in place, but can not be used to perform an import and should only be used to diagnose problems.
To cancel the export:
curl -u <adminusername> -s -n -X POST -H 'Content-type: application/json' http://localhost:7990/rest/api/1.0/migration/exports/<Job ID>/cancelReplace <Job ID> with the "id" value that was returned from the request that started the export job.
The following values are required to cancel the export (REST Documentation):
| Description | Value |
|---|---|
| URL | /rest/api/1.0/migration/exports/<Job ID>/cancel |
| HTTP verb | POST |
| Authentication | Basic |