IMPORTANT: The TeamCity plugin will reach its End Of Life starting November 1, 2021.
After this date, WhiteSource will no longer provide standard support, including updates and fixes, for the deprecated plugin. Extended Support, which is limited to configuration and Support troubleshooting, will continue until May 1, 2022. Following this date, the TeamCity plugin will no longer be supported by WhiteSource. Please make sure to migrate to the Unified Agent before the end of standard support on November 1, 2021 to maintain full support of your product.
The plugin integrates automatic open source management with Jetbrains TeamCity.
Once set up, all usage of open-source software in the organization will be continuously and automatically in sync with WhiteSource.
New projects will be created
Existing projects will be updated
Policies will be enforced on every action, failing the build if necessary.
The plugin currently support build steps with either Maven, Ant, or shell script Runner types.
How it Works
On execution, the plugin will determine which open source is currently used by your project and send it to WhiteSource.
No source code is scanned. Only descriptive information is sent over the wire.
WhiteSource uses the collected information to create new projects or update existing ones.
Policy Check Flow
The plugin will check each new library against the organizational policies. If any library is automatically rejected by some policy, the build will fail. Otherwise your account will be updated.
An informative report of the results will be generated regardless of the outcome.
Installing the Plugin
Download the plugin:
Installation of the plugin is done directly via the TeamCity GUI:
Go to Administration > Server Administration > Plugins List.
Click Upload plugin zip, and navigate to the location of the plugin's zip file.
Restart the TeamCity server (this task can also be done via the TeamCity GUI).
Using the Plugin
Start by configuring the global settings, these settings will be applied to every project in your TeamCity environment. Then, setup the jobs that should interact with WhiteSource.
Once the plugin is installed go to Administration > Integrations > WhiteSource.
Organization Token: A unique identifier of the organization. You can retrieve it in the Admin Integration API page.
User Key: Unique user key. See User Level Access Control in Integrations and APIs for more information.
Policy Check: Checks that the introduced open source libraries conform with organization policies.
Check only new libraries: Check that the newly introduced open source libraries conform with organization policies.
Force check all libraries: Check that all introduced open source libraries conform with organization policies.
Disable: Disable policies check when updating WhiteSource.
Force Update: Updates organization inventory regardless of policy violations.
Fail on Error: Indicates whether or not to fail the build on a general error (e.g. network error).
Service URL: URL of the environment on which the WhiteSource organization is hosted. The default is “https://saas.whitesourcesoftware.com”; therefore organizations hosted on that can leave this field blank.
Connection Timeout (optional): Connection timeout value in minutes. If the field is left blank, the value is 60 minutes.
Proxy Server (optional): If TeamCity is behind a firewall then you should select the checkbox. As displayed in the following screenshot, once the checkbox is selected, newly displayed fields can be filled in, in order to allow communication with the WhiteSource servers.
Environment Variable - Skip plugin
By setting SKIP_WHITESOURCE_PLUGIN to true the plugin will be disabled.
Number of connection retries when unable to connect to WhiteSource service (default value is 1).
Connection Retries Interval
Connection interval in seconds between two connection retries to WhiteSource service (default value is 3 seconds).
Job Specific Settings
Enable the plugin for each job you want to use to update WhiteSource.
Only supported runner types will have these options visible.
Build runners that have no concise system for managing dependencies require a different configuration.
What we're looking for is descriptive information about each library used. What we need to know is which libraries to include and where we can find them, that is the sole purpose of the configuration.
The plugin is executed when the runner finishes. Sample log section:
First release of the plugin.