Connecting to an external version control repository

If your organization already uses a shared repository for version control, you can configure Anaconda Enterprise to use that repository instead of the internal Git server. To associate an external repository with Anaconda Enterprise, you simply need to provide the information required to connect to it.

After you do so, platform users will be able to access the repository within their sessions and deployments without having to leave the platform. Anaconda Enterprise creates a repository for each project that’s created by platform users.

Anaconda Enterprise supports integration with the following external repositories:

External repository Supported versions
Bitbucket Enterprise 5.9.1, 5.12.1, 5.15.0, 5.16.5, 6.2.0, 6.8.0
Bitbucket Cloud bitbucket.org
GitHub Enterprise 2.15, 2.16, and 2.17
GitHub Cloud github.com
GitLab Enterprise 10.4.2, 10.7.1, 11.10.0, and 12.1.6
GitLab Cloud gitlab.com

Warning

If you are going to use an external repository for version control, we strongly recommend you set it up before users start creating projects in Anaconda Enterprise. If your organization changes Git hosting services, and you therefore need to migrate projects from one version control repository to another, we recommend you follow the process outlined here.

NOTES:

  • Neither Bitbucket.com or GitLab.com support versioning of archive downloads and app deployments. In other words, the latest revision will always be downloaded or deployed.
  • To provide permission granularity and maintain parity with your Git hosting solution, Anaconda Enterprise will grant individual platform users access to individual repositories. To prevent default permissions being applied to all users within a group, users cannot belong to the given organization or group.
  • Platform users will be prompted for their personal access token before they create their first project in Anaconda Enterprise. We recommend you advise users to create an ever-lasting token, so they can retain permanent access to their files from within Anaconda Enterprise. The specific auth token permissions required for each repository are outlined here.

Before you begin, gather the following information:

  • The fully qualified domain name (FQDN) of your versions control server
  • The organization, team or group name associated with your service account
  • The username of the Administrator for the organization, team or group. This user will require full Admin permissions.
  • The personal access token or password required to connect to your version control repository

To associate a specific version control repository with a project:

  1. Log in to Anaconda Enterprise, select the Menu icon icon in the top right corner and click the Administrative Console link displayed at the bottom of the slide out window.
  1. Click Manage Resources.
  2. Log in to the Operations Center using the Administrator credentials configured after installation.
  3. Select Configuration from the menu on the left.
  4. Use the Config map drop-down menu to select the anaconda-enterprise-anaconda-platform.yml configuration file.

Warning

Please ignore the other entries in the Config maps and Namespace drop-downs. They impact the underlying Kubernetes system, so making changes to them may have unintended consequences or cause the platform to behave unpredictably.

  1. Locate the git section of the configuration file. The default behavior is to use the internal Anaconda Enterprise repository for version control (see default settings pictured below).
../../_images/new-git-defaults.png

  1. To override this default setting, uncomment the Example external repo configuration section of the Config map, and replace the placeholder settings with the correct values for your organization’s repository:
../../_images/new-git-external.png

Where:

name = A descriptive name for the service your organization uses.

type = The type of version control repository your organization uses: github-v3-api (GitHub Enterprise and Cloud), bitbucket-v1-api (Bitbucket Server), bitbucket-v2-api (Bitbucket Cloud), or gitlab-v4-api (GitLab Cloud and GitLab server).

NOTE: The values for this parameter have changed from AE 5.3.0.

url = The URL of the API (e.g., https://api.github.com/, https://api.bitbucket.org, or https://gitlab.com).

credential-url = The URL to authenticate against for repository operations such as cloning and pushing.

NOTE: This parameter replaces the credential-hostname parameter used in AE 5.3.0.

repository = Must be '{owner}-{id}' encased in single quotes.

organization = The name of your Github organization, Bitbucket team, or GitLab group. (Bitbucket does not support dashes in team names.)

username = The username associated with the Administrator account at Github, Bitbucket, or GitLab. This account must have full Admin permissions.

auth-token = The Github personal access token, Bitbucket app password, or GitLab access token for the Administrator account associated with the username. (You must enable 2FA to get personal access tokens in GitLab.)

  1. Comment out the Internal repo configuration section of the Config map that follows, as it relates to the Anaconda Enterprise internal Git server settings that you are overriding:
../../_images/new-git-internal.png

  1. Click Apply to save your changes to the Config map.

  2. To update the Anaconda Enterprise server with your changes, restart services by running these commands on the master node:

    sudo gravity enter
kubectl get pods | grep ap- | cut -d' ' -f1 | xargs kubectl delete pods

To verify that Anaconda Enterprise users can access the version control repository you added, create a project. See Working with projects for more information.