Migrating projects between version control repositories¶
If your organization has changed Git hosting services, and you therefore need to migrate projects from one supported version control repository to another, we recommend you follow this high-level process:
Update the Anaconda Enterprise config map with the information required to connect to the external version control repository.
To run the project migration script, you’ll need Administrator access to a command line tool that can run bash or Python scripts on the master node of the Anaconda Enterprise cluster.
You’ll also need the Postgres database password, origin Git host token/password, and destination Git host token/password.
If you haven’t already done so, install the version of conda provided with the Anaconda Enterprise installer on the master node:
After conda is finished installing, login to the terminal again.
Install git, using the command that’s appropriate for your environment:
yum install git
apt install git
Use the following command to create the conda environment:
conda create --name migrate --file anaconda-enterprise-5.3.1-56.gf54c3abad/environment.txt
Temporarily disable reverse proxy authentication by adding the following key-value pair to the
gitsection of the
anaconda-enterprise-anaconda-platform.ymlfile used to configure the platform to use an external version control repository:
Run the following command to restart the associated pod on the master node:
kubectl delete pod -l 'app=ap-git-storage'
Using the migration tool¶
Running this script creates a local origin repository containing all of the Anaconda Enterprise projects that were stored in the existing remote origin repository, then pushes the local origin repository to the new remote destination repository.
On the master node of the Anaconda Enterprise cluster, copy the
migrate_projects.pyscript from the location where you saved the Anaconda Enterprise installer tarball using the following command:
sudo cp migrate_projects.py /opt/anaconda
Create a user mappings file that maps Anaconda Enterprise user IDs to Git user IDs. This is a colon-separated text file where the first field is the AE user name, and the second field is the corresponding Git user name. For example:
Either create or place this file in the same directory as the
migrate_projects.py script (
/opt/anaconda). You’ll refer to this file by name when you run the migration script in the next step.
/opt/anacondaand run the following command to begin migrating your projects, replacing all placeholder values with actual values.
migrate_projects.py --postgres-host localhost --origin-api-url <https://localhost:8443/> --origin-username root --dest-api-url <https://githost.domain.com/> --dest-username root --dest-organization <org_name> --dest-user-mappings <user-mappings.txt> --force-migrate --parallel 4
--help to view information about the command options and arguments.
Enter your Postgres database password when prompted.
Enter your origin Git host token/password when prompted.
Enter your destination Git host token/password when prompted.
After the script finishes migrating the projects, re-enable reverse proxy authentication by editing the key-value pair you previously added to the
git section of the
anaconda-enterprise-anaconda-platform.yml file, so it looks like the following:
If you do not re-enable reverse proxy authentication, Anaconda Enterprise will not work.
If you’ve migrated to https://github.com, whenever a user is added to a project as a collaborator, they’ll be sent an invitation to collaborate via email. They’ll need to accept this invitation to be able to commit changes to the repository associated with the project. This does not apply to Github Enterprise.