The Component Configuration File is a YAML file with erb-syntax where you configure specific instructions for MAIA Agent. It defines the steps needed to perform and/or send information about checkout, build, fetch, test and deploy a specific component and track to MAIA web app.
The file must be stored at the root of your repository. If more than one track is built, a new configuration file must be checked out before the track is built.
The default name name of the file is MAIA.yml after installation, but can be redefined by editing the parameter COMPONENT_CONFIG_FILE in the environment file.
The column headed M/C/O in the table refers to whether the parameter/attribute is mandatory, conditional or optional. The following notation is used:
Meaning | |
---|---|
M | Mandatory – always present. |
C | Conditional – present under certain conditions (as specified in the description). |
O | Optional – can be present. |
MAIA Agent is used for scanning (SCAN) or/and Build/Deploy/Test (BDT), which activity is indicated in the parameter list below.
Parameter | M/C/O | Description | |
---|---|---|---|
version | M | The protocol version of the component configuration file. The protocol version must be 5.0. | |
component_name | O | The name of the component in MAIA application. | |
rev | M | The revision of the component. The revision can be a string or a call to a shell script. | |
subcomponents | C | The list of all the sub components the component has in MAIA application, if the component is a collection. The sub component can contain collections in any number of levels. | |
label | C | The label of a previously built sub component. If the label is defined, the same code that was used in the previous build will be checked out again to be built. The label cannot be used together with the parameter revision or the parameter track. | |
name | M | The name of a sub component. | |
rebuild | O | Defines whether the sub component, together with any sub component, will be checked out and rebuilt. If true the sub component, together with any sub component, will be checked out and rebuilt. (Default) If false, the sub component will not be checked out, but its sub component will be checked out. The sub component will not be rebuilt. | |
revision | C | The client defined revision of a previously built sub component. If the revision is defined, the same code that was used in the previous build will be checked out again to be built. The revision cannot be used together with the parameter label or the parameter track. | |
track | C | The name of a track if the last commit of a sub component is fetched. The track cannot be used together with the parameter label or the parameter revision. | |
test | O | Defined whether tests on sub components should be run. Test is set to true by default. | |
clean | O | Section with instructions for the build clean phase. | |
cmd | O | The commands that will be executed during the build clean phase. | |
prepare | O | Section with instructions for the build preparation phase. | |
cmd | O | The commands that will be executed during the build preparation phase. | |
build | O | Section with instructions for the build phase. | |
cmd | O | The commands that will be executed during the build phase. | |
dependency_generator | O | The instruction for how to collect information about external software dependencies during the build phase. See information below. | |
fetch | O | Section with instructions for the fetch phase. | |
cmd | O | The commands that will be executed during the build fetch phase. | |
deploy | O | Section with instructions for the deploy phase. | |
cmd | O | The commands that will be executed during the deploy phase. | |
deploy_path_generator | O | The scripts called in the parameter cmd. The scripts generate the names and the paths to the deliverables specified in the section deliverables, and post the information to MAIA WebAPP. If the section deliverables is missing, the information will not be posted to MAIA WebApp. See information below. | |
test | O | Section with instructions for the test phase. | |
cmd | O | The commands that will be executed during the test phase. | |
prepare_cmd | O | Defines the commands that will be used to prepare for a test. | |
suites | O | A list of of tests suites that will be run. | |
deliverables | O | Section with instructions for which deliverables to include in the build. The deliverables can be built or fetched. | |
name | O | The name of a deliverable. The name is the same as the deliverable name generated when running the instructions in parameter deploy_path_generator. | |
unpack | O | The commands used to unpack the deliverable during the fetch stage. |
references one ore more scripts that fetches external software for the build. The script must print to standard output (stdout) and use CycloneDX json format.
Example:
{
"bomFormat": "CycloneDX",
"specVersion": "1.3",
"version": 1,
"components": [
{
"type": "library",
"name": "libxml2",
"version": "2.9.9",
"purl": "pkg:generic/libxml2@2.9.9",
"externalReferences": [
{
"type": "website",
"url": "http://xmlsoft.org/sources/libxml2-2.9.9.tar.gz"
}
],
"licenses": [
{
"license": {
"name": "MIT",
}
}
}
]
}
]
}
must reference a user defined script that returns the deliverables on a build that:
Example of script printed to standard output.
Image http:/mynexus.com/repositories/r-abc133/base.iso
Signature http:/mynexus.com/repositories/r-abc133/base.iso.sig
There are a number of predefined variables that can be used within the <%%> signs in the Component configuration file:
Example :
Parameter | Description |
---|---|
component_src_root | The directory that the source files of the component are checked out to. The component_src_root is the default working directory when executing commands. The default value is defined by the expression 'SRC_ROOT/ |
top_src_root | The directory where source files of the top component are checked out. |
build_root | The directory that stores the result of a build. It is defined by the variable BUILD_ROOT in the environment file. |
log_root | The directory that temporary files, log files, debug files and similar files are written to. It is defined by the variable LOG_ROOT in the environment file. |
deliverable_root | The directory that deliverables are unpacked to. It is defined by the variable DELIVERABLE_ROOT in the environment file. |
rev | The revision of the component. The revision can be a string or a call to a shell script. |
grev | The global revision of the Subversion repository. |
build_label | The build label, if code has been checked out by using the parameter label. |
tested_rev | The revision used in tests to define the system under test. |
tested_component | The name of the component used in tests to define the system under test |
maia_core | The URL to the package maia_core. |
---
version: 5.0
rev: <%= `make -s version`.chomp %>
prepare:
cmd: make clean
build:
cmd: make build
dependency_generator: make -s dependency_list
---
version: 5.0 # Protocol version, must be 5.0
component_name: template # Optional. If defined it must be the same as the name of the component.
rev: 1.0.2 # User-specified revision
subcomponents: # If this is a collection, specify sub component to builds before this component
- rf-common # Default, checkout and build with latest in track 'main'
- name: ps-common # Checkout and build with latest in a specified track
track: bug-fix4
- name: camel-rf-net # Do not checkout or build, reuse from build label
label: CAMEL_RF_NET_1.2-4
rebuild: false
- name: rf-common # Do not checkout or build, reuse from revision
revision: 4.0.5
rebuild: false
- name: rf-common # Checkout and rebuild, with label given by environment
label: <%= ENV['RF_COMMON_LABEL'] %>
rebuild: true
test: false # Don't test
clean:
cmd: rm -rf <%= build_root %>
prepare:
cmd: make clean
build:
cmd:
- mvn clean install
- rm -f <%= log_root %>/depend.txt
- mvn dependency:list > <%= log_root %>/depend.txt
dependency_generator:
- grep-dependencies <%= log_root %>/depend.txt <%= src_root %>/pom.xml <%= src_root %>/features.xml
deploy:
cmd: mvn deploy |tee > <%= log_root %>/deploy.txt
deploy_path_generator: grep-nexus-path <%= log_root %>/deploy.txt
test:
prepare_cmd:
- make clean_test
suites:
- name: system_test
cmd:
- do_test --suite regression.xml <%= rev %> <%= tested_component %> <%= tested_rev %> <%= maia_core %>
deliverables:
- name: mm-features # Specify deliverables and how to unpack them
unpack:
cmd: 'tar xf <%= deliverable_root %>/mm-features-<%= rev % >.jar'
---
<% test_arg = "TEST_SUITE_ID=$test_suite_id API_TOKEN=#{api_token} ARTIFACT_ID=#{artifact_id} KAFKA_BROKERS=#{kafka_brokers} KAFKA_TOPIC=#{kafka_topic}" %>
<% set_env = "export PATH=#{build_root}/bin:$PATH; export LD_LIBRARY_PATH=#{build_root}/lib:$LD_LIBRARY_PATH;" %>
version: 5.0
rev: '<%= rev=`ruby $BLT_IPV_ROOT/bin/read_revision.rb local_repository/Makefile`.chomp %>'
prepare:
cmd: cd local_repository; make clean prepare
build:
cmd: cd local_repository; make build install
dependency_generator:
- <%= set_env %> ruby gem_dependencies.rb local_repository/maia/Gemfile.prod
- <%= set_env %> cd local_repository/maia && ruby npm_dependencies.rb
system_test:
prepare_cmd: cd local_repository/test; make clean
suites:
<% ['models', 'presenters', 'views', 'validations', 'features', 'lib', 'helpers', 'services', 'requests'].each do |r| %>
- name: rspec <%= r %>
cmd: cd local_repository/test; make rspec_test <%= test_arg %> PATTERN=spec/<%= r %>/*
<% end %>
<% ['models', 'jobs', 'helpers', 'lib', 'validations'].each do |m| %>
- name: 'mt <%= m %>'
cmd: cd local_repository/test; make mini_test <%= test_arg %> SUITE=<%= m %>
<% end %>