...
Configure your Bamboo agents
First you need to make sure that any agent that potentially can run a Kiuwan analysis as part of a build plan, has the Kiuwan Local Analyzer (KLA) installed on the same machine, and that you configure a Kiuwan agent-specific capability in the agent. For example, if you install your KLA in C:\KiuwanLocalAnalyzer, you can configure a new agent-specific capability as follows:
From the Bamboo agents admin page select the agent you want to configure
Click the Add capability link
Select Executable from the Capability type dropdown
Select Command from the Type dropdown
Give the new capability a unique label to identify it, KLA for example
Specify the complete absolute path to the KLA command, C:\KiuwanLocalAnalyzer\bin\agent.cmd for example
Repeat this operation for all agents that will run Kiuwan analyses. THe more agents you have with the KLA capability the more analyses you can run in parallel. This will depend on the number of applications you have under continuous development and your build/analysis strategy.
Once you have all your agents configured, you can create (or modify) build plans to run Kiuwan analyses.
Create Bamboo builds for projects to analyze
...
Alternatively you could create global variable for your credentials. In that case the same credentials will be used across your build plans. It is up to you what you want to do.
Create an analysis stage
Next you can create a stage to add the aKiuwan analysis job to it or add a job in an existing stage (like we have done here in the default stage). In the Job definition, first you can configure a requirement, searching for the KLA capability and specify the it must ‘exist’. This ensures that the job is sent to an agent that has the KLA installed.
Then go to the Tasks tab to configure the Kiuwan analysis task. Kiuwan needs the source code to analyze it, so make sure that there is a ‘Source Code Checkout’ task before anything else.
After that at least add a Script task to run the Kiuwan analysis. You can configure more tasks (like build) in this stage or just use it only for the analysis. It is up to you how you want to do it.
This is a PowerShell example, using some PowerShell commandlets. You can come up with a similar script for Linux shells mimicking the functionality.
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
$project_name = "${bamboo.planName}".Split("-")[0].Trim()
agent -n "$project_name" -s ${bamboo.build.working.directory}\src -l "Bamboo build ${bamboo.buildNumber}" -c --user ${bamboo.KiuwanUser} --pass ${bamboo.KiuwanPassword} -wr
exit $lastexitcode |
Alternative Kiuwan analysis. Delivery
Kiuwan can run 2 different types of analysis baseline and delivery. In the previous example the script Kiuwan command runs a baseline analysis if you want to run a delivery analysis you script will look something like:
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
$project_name = "${bamboo.planName}".Split("-")[0].Trim()
$change_request = "New CR"
agent -n $project_name -s ${bamboo.build.working.directory}\src -l "${bamboo.shortPlanKey}${bamboo.shortJobKey}-${bamboo.buildNumber}" -as completeDelivery -crs resolved -cr ${bamboo.planRepository.branch} -bn ${bamboo.planRepository.branch} --user ${bamboo.KiuwanUser} --pass ${bamboo.KiuwanPassword} -wr
exit $lastexitcode |
A good use case could be to run a Delivery analysis for every pull request, so the policy is applied before the merge. The merge can be blocked if the pull request doesn’t pass the Kiuwan audit.
Run your build plans
You can run the build plan manually or define different triggers and strategies to run them automatically.
What you do will depend on your development process.
You can follow the Kiuwan task execution on-line or check the logs after execution:
