Source Control Configuration Overview

Overview

Nexus Lifecycle can connect to your Source Control Management (SCM) system to scan your projects in development. Configuring Lifecycle to work with your SCM repositories requires an access token set at the Root Organization. This page provides an overview of the SCM Configuration process.

The IQ Server Base URL must be configured for Source Control Features to function.

Configuration Overview Checklist

The following lists the steps to connect your Source Control Management system to Nexus Lifecycle. See the Next Steps section for details on how to complete each step. 

  1. Create SCM Access Token
  2. Configure Base URL in IQ Server
  3. Select Source Control Configuration at the Root Organization
  4. Select Source Control Management System 
  5. Enter your Access Token
  6. Enter the Default Branch
  7. Toggle Use SSH for Git Operations
  8. Toggle Automated Pull requests 
    • We recommend disabling it when used with Easy SCM Onboarding
  9. Toggle Pull Request Commenting
    • Recommended for all repositories. 
  10. Select Source Control Evaluations
    •  Recommended for all repositories. 
  11. (optional) Create separate access tokens for IQ Server Organizations using different SCM Systems
  12. (optional) Configure additional SCM Features

Feature Configuration

The table below lists each feature and how it is configured.

The IQ Server Base URL must be configured for Source Control Features to work properly.

FeatureConfiguration
Automatic Pull RequestsConfigured at the Organization level.
  • Disabled by default
SSH Operations

Configured at the Organization level.

  • Disabled by default
Pull Request Commenting

Configured at the Organization level.

  • Enabled by default
Pull Request Line CommentingEnabled with Pull Request Commenting.
Source Control Evaluations

Configured at the Organization level.

  • Enabled by default
Automated Commit FeedbackConfigured in SCM Provider.
Automatic SCM ConfigurationConfigured on the page accessed through Settings Menu.
Easy SCM OnboardingApplication import feature. 
Requires SCM Access token configured. 
Bitbucket Code InsightsConfigured with Pull Request Commenting

Next Steps

Create Access Token

Select your SCM provider below for information on creating an access token and configuring your SCM System for use with Nexus Lifecycle.

Required Token Permissions

FeatureAzure DevOpsBitbucket CloudBitbucket ServerGitHubGitLab
Automated Commit FeedbackCode: Read & Write
Read under RepositoriesRead under Repositoriesrepo:status

api

Automated Pull RequestsCode: Read & WriteWrite under Pull Requests
Write under Repositoriesrepoapi + write_repository
Pull Request CommentingCode: Read & Write

Write under Repositoriesrepoapi
Pull Request Line Commenting
Write under Repositoriesrepoapi
Bitbucket Code InsightsWrite under RepositoriesN/AN/A

IQ Configuration

Add your SCM Access Token to the Root Organization in IQ Server to enable Lifecycle Features.

Dealing with SCM API rate limits

When an SCM system's API interacts with Nexus IQ, the SCM system enforces some form of limitation on the volume and frequency of interaction with their APIs; GitHub appears to be the most restrictive. GitHub limits API requests to 5000 per hour per user and specifies at least a one-second delay between requests. As the number of applications that IQ Server manages increases, the workload demanded of the SCM API also increases. This translates to a delay between, for example, the time the workload is initially processed and the time before a comment is added to a pull request.

Since the SCM system API limitations are per user, organizations with hundreds or thousands of repositories should create multiple users/access tokens and use different tokens for different sub-organizations in IQ Server. This allows IQ Server to perform more work in parallel with the SCM system. The additional tokens must be for distinct SCM users — multiple tokens for the same user will not help since the API rate limits apply at the user level and not the token level. A reasonable starting point would be one user/token for every 500 repositories.