...
This topic provides instructions on how to enable a global repo configuration which will affect all new repositories to be integrated using either WhiteSource Mend for GitHub.com, WhiteSource Mend for GitHub Enterprise, WhiteSource Mend for Bitbucket Server/Data Center, or WhiteSource Mend for GitLab Server. For information on how to migrating existing repositories to the global configuration, see here. Using this global configuration, you will be able to define a configuration template file (repo-config.json), which can be inherited by all future integrated repositories. You will also be able to define a global configuration (not specific to a repository) file (global-config.json) for your integration. The currently-supported global configuration enables you to define how the user onboarding flow will occur for your integrated repositories.
...
Ensure that you have already integrated the relevant repository platform with WhiteSourceMend. If needed, refer to the installation sections of the relevant platform below:
WhiteSource Mend for Bitbucket Server / Data Center
WhiteSource Mend for GitHub Enterprise
WhiteSource Mend for GitLab Server
WhiteSource Mend for Azure Repos
Enabling the Global Configuration
(Only for Self-Managed integrations) Create a new organization (GitHub Enterprise), Group (Gitlab Server), Project (Bitbucket Server/Data Center) named whitesource-config (the name must be exactly as specified here) in your integrated repository platform.
(Only for AzureRepos) This integration is using Global Configuration by default so just follow the installation steps of the WhiteSource Mend for Azure Repos documentation.
Create a new repository named whitesource-config (the name must be exactly as specified here). In Self-Managed integrations, this repository needs to be inside the whitesource-config entity you created in the previous step.
Add the new whitesource-config repository to your integration. Based on your relevant platform, refer to the correct section:
WhiteSource Mend for Bitbucket Server / Data Center
WhiteSource Mend for GitHub Enterprise
WhiteSource Mend for GitLab Server
The whitesource-config repository will now contain a README file and two new configuration files (automatically created by the integration), repo-config.json and global-config.json. Configure these files by referring to the following sections and then continue in this procedure.
Add repositories you want WhiteSource Mend to scan, to your integration.
...
This configuration template file is a JSON formatted file that will be applied globally to each newly selected integrated repository. It provides configurable parameters for a WhiteSource Mend scan. All new integrated repositories will inherit the configuration set in this file, unless explicitly overridden by a local .whitesource file in the relevant repository. Refer to the following sections for information on which parameters can be added to the repo-config.json file:
WhiteSource Mend for Bitbucket Server / Data Center
WhiteSource Mend for GitHub Enterprise
WhiteSource Mend for GitLab Server
global-config.json
...
Parameter | Type | Description | Required | Default | ||||
---|---|---|---|---|---|---|---|---|
repoConfigMode | String | The configuration mode to be used on all integrated repositories. There are three options:
| Yes | createOnboardingPR | ||||
repoConfigFileName | String | It is possible to rename the .whitesource configuration file added to an integrated repository. NOTES:
| No | .whitesource | ||||
branchProtectionRule | Automatically create a “WhiteSource “Mend Security Check” branch protection rule for all branches configured by the “baseBrances” property. This will only occur for newly onboarded repositories. NOTES:
| No | “none” | |||||
settingsInheritedFrom | Add an option for a regular account repo-config.json or global-config.json file to inherit settings from the whitesource-config account’s global-config.json file. For example, a global-config.json file in {someOrg}/whitesource-config could inherit settings from the whitesource-config/whitesource-config file. If this parameter is enabled, after creating a whitesource-config file inside the repos of the given organization, it will be automatically populated with the settings from the whitesource-config/whitesource-config file. NOTE: You can override specific parameters that are relevant only in the specific repository by adding these after this parameter. Examples: Using only values defined in the global configuration:
Using values defined in the global configuration and overriding the scan settings parameters:
| No | “none” |
...
Parameter | Type | Description | Required | Default | ||
---|---|---|---|---|---|---|
includedOwners->exactNames | Array | Define a whitelist of GitHub Organizations and/or GitHub repository owners who can integrate with the WhiteSource Mend integration. NOTE: This applies to WhiteSource Mend for GitHub Enterprise and WhiteSource Mend for GitHub.com only. For example:
| No | Empty | ||
allowedUserAccounts->exactNames | Array | Provide a way to limit the integration to organization accounts and block all or specific user accounts. If the “exactNames” property is empty all user accounts will be blocked. If the object is missing, no limitation on account type will be enforced. When a blocked account is trying to install the integration it will be automatically uninstalled. NOTE: Only valid for the GitHub Enterprise integration.
| No | Null |
Manually Triggering Repository Scans
NOTE: Relevant only for WhiteSource Mend for GitHub Enterprise Integration and WhiteSource Mend for GitHub.com Integration.
...
Ensure you performed the steps described in Enabling the Global Configuration.
Go to the whitesource-config repository.
Add a new file named migration.json in the default branch.
Inside the file, add the following content (to change parameters and values, refer to the table below):
Code Block { "migrationMode": { "changeType": "inheritance", "openPR": true } }
To run the migration, commit and push the file.
A WhiteSource Mend Security Check (as part of a Check Run for GitHub.com/GitHub Enterprise, Commit Status for GitLab, and Build Status for Bitbucket Server) will be generated and display a summary of the migrated repositories. In addition, the migration.json file will be deleted after the migration is completed.
NOTE: In WhiteSource Mend for Bitbucket Server, the migration.json file needs to be manually removed.
...
Parameter | Type | Description | Required? | Default | ||
---|---|---|---|---|---|---|
migrationMode.changeType | String | Type of change to perform as part of the migration. There are two possible values:
| No | inheritance | ||
migrationMode.openPR migrationMode.openMR | Boolean | Whether an onboarding PR/MR should be created for the migrating repositories. NOTE: When set to false, every migrating repository that currently contains a .whitesource file will trigger an automatic scan after these are migrated. This may affect overall performance of the integration depending on how many migrating repositories you have. | No | true | ||
migrationMode.triggerScan | Boolean | Control whether the migration should trigger a scan after completion. NOTE: this parameter is relevant only when using migrationMode.changeType=inheritance. | No | true | ||
includeRepos | Array | Provide a list of specific full repository names (owner/repo_name) on which the migration should run. NOTE: You cannot use includeRepos together with excludeRepos as part of a migration. Example:
| No | Empty | ||
excludeRepos | Array | Provide a list of specific full repository names (owner/repo_name) on which the migration should not run. NOTE: You cannot use excludeRepos together with includeRepos as part of a migration. Example:
| No | Empty |