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 repositorySupported versions
Bitbucket Enterprise5.9.1, 5.12.1, 5.15.0, 5.16.5, 6.2.0, 6.8.0
Bitbucket Cloudbitbucket.org
GitHub Enterprise2.15, 2.16, and 2.17
GitHub Cloudgithub.com
GitLab Enterprise10.4.2, 10.7.1, 11.10.0, and 12.1.6
GitLab Cloudgitlab.com
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 version 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 in the top right corner and click the Administrative Console link displayed at the bottom of the slide out window.
  2. Click Manage Resources.
  3. Log in to the Operations Center using the Administrator credentials configured after installation.
  4. Select Configuration from the menu on the left.
  5. Use the Config map drop-down menu to select the anaconda-enterprise-anaconda-platform.yml configuration file.
    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.
  6. 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).
  7. 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:
    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 (for example, 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.)
    The url and credential-url attributes must contain all lowercase characters.
  8. 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:
  9. Click Apply to save your changes to the Config map.
  10. To update the Anaconda Enterprise server with your changes, restart services by running these commands on the master node: 
    sudo gravity enter
kubectl delete --wait=false $(kubectl get pods -o name|grep ap-)
To verify that Anaconda Enterprise users can access the version control repository you added, create a project. See Working with projects for more information.