Integrating FOSSA with TeamCity

This guide is for you to set up a FOSSA project with a TeamCity workflow.

Getting Started

The TeamCity integration requires fossa-cli our open-source dependency analysis client, to be installed on your CI machine. The client supports all 3 major operating systems (Unix, Darwin/OSX, and Windows).

  • To test the CLI, you can install it in your local environment using the command below or download it directly from our GitHub Releases page.
curl -H 'Cache-Control: no-cache' | bash
# view `fossa` help text
fossa --help

Setup your TeamCity Environment

First, grab a FOSSA API Key from your FOSSA account under your Integration Settings.

NOTE: If you are the maintainer of a public repository you should consider making your API key a Push Only Token.


First add a TeamCity Environment Variable to your Parameters settings:

Add new parameter


Select the "Kind" as "Environment variable (env.)
Add your FOSSA API Key


Add FOSSA steps to BuildConfig

Add a new build step by clicking on the add build step


Select Command Line option from the drop-down list


Use the information below to complete the “Custom script” section of the Build Step

curl -H 'Cache-Control: no-cache' | bash
fossa analyze

Use FOSSA_API_KEY which you created for the user.
Refer to the FOSSA CLI User Manual for in-depth information about using fossa-cli tool.


Save this build step and you can verify by running build config.

Blocking CI Builds w/ FOSSA Issue Status

You an also create a step in TeamCity that will allow you to pass/fail a build based on the scan status in FOSSA.

To accomplish this, simply add an additional build step to call “fossa test”


Note, that “Advanced options” have been expanded and the Execute step “If all previous steps finished successfully” is configured

The fossa test command will poll or your local FOSSA appliance for updates on your scan status until it gets a response. Then, it will report a relevant exit status to the CI step (to block a failing build) and render rich details about issues directly inline to the TeamCity test results.

You can customize a timeout on this step using the fossa test --timeout {seconds} flag documented here. The default timeout is set to `600 seconds (10 minutes), but will only be hit in exceptional cases -- most scans should return well under the timeout window.