Versions Compared

Old Version 68

changes.mady.by.user Vital Batyr

Saved on

compared with

New Version 69

changes.mady.by.user Michelle Friedman

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

  1. (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.

  2. (Only for AzureRepos) This integration is using Global Configuration by default so just follow the installation steps of the WhiteSource for Azure Repos documentation.

  3. 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.

  4. Add the new whitesource-config repository to your integration. Based on your relevant platform, refer to the correct section:

  5. 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.

  6. Add repositories you want WhiteSource to scan, to your integration.

...

...

Parameter 

Type

Description

Required 

Default

exactNames

Array

Provide a list of specific repositories to ignore from the integration. For example:

Code Block
"ignoredRepos": {
  "exactNames": ["user/myrepo", "user/testrepo"]
}

No

Empty

Account

...

Management

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 integration.

NOTE: This applies to WhiteSource for GitHub Enterprise and WhiteSource for GitHub.com only.

For example:

Code Block
"includedOwners": {
  "exactNames": ["MyOrg", "MyUserName"]
}

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.

Code Block
{
  "allowedUserAccounts": {
    "exactNames": ["userName1", "userName2"]
  }
}

No

Null

...

The repository list is limited to 10. If there are more than 10, no repositories will be scanned, and a check run saying so will be created.

If a branch name is not specified - , the default branch will be scanned.

...

  • Name of the zip file: scanner_logs_{SCAN_TOKEN}.zip

  • The name of the ws-logs repo is configurable using the env var WS_LOG_REPO_NAME

  • If that the repo whitesource-config/ws-logs does not exist - then , the manual scan will not run , and there will be a check run explaining will explain why:

Migrating Existing Repositories to the Global Configuration

...

  1. Ensure you performed the steps described in Enabling the Global Configuration.

  2. Go to the whitesource-config repository.

  3. Add a new file named migration.json in the default branch.

  4. Inside the file, add the following content (to change parameters and values, refer to the table below):

    Code Block
    {
	"migrationMode": {
		"changeType": "inheritance",
		"openPR": true
	}
}

  5. To run the migration, commit and push the file.
    A WhiteSource 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 will display a summary of the migrated repositories. In addition, the migration.json file will be deleted after the migration is completed.
    NOTE: In WhiteSource for Bitbucket Server, the migration.json file needs to be manually removed.

Info

For self-hosted organizations, if the migration.json file is pushed from the global configuration repository of a global organization (whitesource-config/whitesource-config), the migration will affect all the integrated organizations. If the migration.json file is pushed from the global configuration repository of a regular organization (regular-org/whitesource-config), the migration will affect only the repositories from this organization.

migration.json File Parameters

Parameter

Type

Description

Required?

Default

migrationMode.changeType

String

Type of change to perform as part of the migration.

There are two possible values:

  • inheritance - The migrating repositories will inherit from the global configuration

  • deletion - The .whitesource file (if found) will be removed from the migrating repositories. Note the following:

    • This should only be used when repoConfigMode in the global-config.json file has the value noWhitesourceFile. Otherwise, no migration will be performed.

    • In WhiteSource for Bitbucket Server, the deletion option is not available. You will need to manually delete the .whitesource file for each migrated repository.

  • fixInheritance - The migration will update existing inheritedFrom parameter values in repo-level .whitesource configuration files, to the correct whitesource-config repository.

    • This parameter can be used in case the Global Configuration repository was moved or renamed since the initial integration.

No

inheritance

migrationMode.openPR
(WhiteSource for GitHub Enterprise, WhiteSource for GitHub.com, and WhiteSource for Bitbucket Server/Data Center)

migrationMode.openMR
(WhiteSource for GitLab)

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:

Code Block
"includeRepos": ["whitesource/unified-agent-distribution", "whitesource/jenkins-whitesource-plugin"]

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:

Code Block
"excludeRepos": ["whitesource/unified-agent-distribution"]

No

Empty