Results

Component configuration file

Updated:2022-11-22

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.

Parameters

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.


Parameter dependency_generator:

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",
            }
          }
        }
      ]
    }
  ]
}


Parameter deploy_path_generator:

must reference a user defined script that returns the deliverables on a build that:

  • Print to standard output (stdout).
  • Print one line for each deliverable with syntax .

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


Predefined variables

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/', where SRC_ROOT is defined in the environment file. The value of the SRC_ROOT can be by the option --path when running the command maia checkout.
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.


MAIA.yml, simple example file:

---
version: 5.0
rev: <%= `make -s version`.chomp %>
prepare:
 cmd: make clean
build:
 cmd: make build
 dependency_generator: make -s dependency_list


MAIA.yml, one more example file:

---
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'


MAIA.yml, another example file:

---
<% 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 %>