1. Bamboo plan.
A dedicated Bamboo plan has been created to launch WS scans of NMaaS components at will.
The name of the plan is nmaas-ws under the gn4-3-wp6-t3-nmaas Bamboo project.
No automated triggers (e.g. either scheduled or push-based) were configured. Plan has to be run manually.
It is worth noting that the scanning process is run within dedicated Docker containers rather than on the Bamboo agents directly. This is a recommended approach.
1.1. Repositories.
The plan uses the same source code repositories as typical plans created for source code integration, Sonar updates or Docker image builds.
1.2. Variables.
On the plan configuration level a set of variables are defined that can be later on referenced from various tasks executed during the overall WS scan setup and execution process.
In our case those include: apiKey, productToken, projectToken as well as productVersion and projectVersion (for each software component to be scanned within this Bamboo plan, e.g. projectTokenPlatform and projectVersionPlatform for the Platform component).
The first three are the identifiers of the GEANT organization and scanned product or project in WS system. They are provided by the WS administrators and must be kept secret and plan variables is a good place to store them. The other two indicate the version of scanned product and project.
Some variables can be later on easily managed by the Bamboo admin for given software project like the product and project versions that are most likely to be bumped from time to time.
1.3. Stages, jobs and tasks.
NMaaS software is composed of 3 major software components the Platform, Portal and Janitor. Each of them is scanned separately in a dedicated Job under the Default Stage of the plan.
Each of those jobs follows the same scheme and is composed of 3 tasks.
The following description will base on the Platform scanning job. The other two are configured in similar matter.
1.3.1. Checking out the source code repository.
The job starts with the execution of a plain Source Code Checkout task in which only the source code repository needs to be provided as a parameter.
1.3.2. Building Docker image.
Next, a Docker task is executed in order to build the Docker container image on which the scanning process will be launched.
The command parameter to be used is Build a Docker image.
A unique name of the image should be given as the Repository parameter together with a Docker registry to be used to store it (e.g. the GÉANT Artifactory).
The desired content of the Dockerfile should be also provided.
The content of the Dockerfile will be slightly different for each software component.
In all the cases JRE and curl should be available in the container.
We are copying the software sources to a known directory on the container, in this case /scan.
We are relying that some WS configuration files were already added to the sources as the run_ws.sh script.
1.3.3. Running the scan inside the Docker container.
The final task is again a Docker task but this time with command Run a Docker container.
In the container environment variables sections a list of environment variables are being defined and assigned values from the previously created Plan variables.
The container is started with the execution of run_ws.sh script in /scan/ws directory.
2. Changes required in the software source code.
In case of NMaaS, for each of the software components, a ws directory was created in the root directory with two files.
Typical content of the run_ws.sh script in provided below. Please note the main scanning script (jar) is run with a number of arguments that are obtained from environment variables that are being set based on the Bamboo plan variables mentioned earlier.
#!/bin/sh echo "Downloading WhiteSource agent..." echo "Running WhiteSource scan..." java -jar wss-unified-agent.jar -apiKey ${API_KEY} -projectVersion ${PROJECT_VERSION} -projectToken ${PROJECT_TOKEN} -productVersion ${PRODUCT_VERSION} -productToken ${PRODUCT_TOKEN} -c ws.config -d ../ |
|---|
The ws.config file contains the configuration of the scanning process specific to particular software component. Below only few first line are included. Please note that the variables are left blank and the ones provided from the command line are being used.
############################################################### # WhiteSource Unified-Agent configuration file ############################################################### # GENERAL SCAN MODE: Files and Package Managers ############################################################### # Organization vitals ###################### # TO BE PROVIDED AS COMMAND PARAMETER #apiKey= #userKey is required if WhiteSource administrator has enabled "Enforce user level access" option #userKey= #requesterEmail=user@provider.com #projectName= # TO BE PROVIDED AS COMMAND PARAMETER #projectVersion= # TO BE PROVIDED AS COMMAND PARAMETER #projectToken= #projectTag= key:value #productName= # TO BE PROVIDED AS COMMAND PARAMETER #productVersion= # TO BE PROVIDED AS COMMAND PARAMETER #productToken= … |
|---|
3. Running the Bamboo plan.
With all the above in place, user can simply run the plan when desired.
