Configuration

Overview

Optionally, you can define the builder behavior by configuring the parameters in the build-parameters section in the mta.yaml file for each module or globally.

For each module, the Cloud MTA Build Tool performs a build operation using a default technology specific for the module type, for example, the npm builder.

For the complete list of available builders and their default behaviors, see Builders Execution Commands.

To find out which builder is applied to a module if the builder parameters are not explicitly set in the MTA development descriptor file (mta.yaml), see Modules' default builder configuration.

The following sections describe in detail how to configure each of the supported builders.

Configuring a builder for a module

To use a non-default builder for a module, specify its name in the builder parameter.


- name: module1
   type: java
   build-parameters:     
     builder: zip

Configuring build order

You can define the dependencies between modules to ensure that they are built in a certain order. In addition, you can use the build results of one module to build another module. Also you can can configure build steps that are performed before building any of the modules.

Defining module build order

To define the build order of modules, in the mta.yaml file, add a requires section under the build-parameters section of the dependent module; that is, a module that should be built only after building another required module. Then specify the required module name as a property of the dependent module’s requires section.

The example mta.yaml file below demonstrates how to build module A after module B:


ID: myproject
_schema-version: '3.1'
version: 0.0.1

modules:

 - name: A
   type: html5 
   path: pathtomoduleA
   build-parameters:
      requires:
        - name: B

 - name: B
   type: html5 
   path: pathtomoduleB

NOTE: The order of modules in the mta.yaml file is not important as long as the requires sections have been coded with the relevant dependencies.

CAUTION: Cyclical dependencies are not allowed. If such dependencies are found, the build fails.

Using build results for building another module

If you want to use the build results of module B for building module A, modify the requires section as follows:


ID: myproject
_schema-version: '3.1'
version: 0.0.1

modules:

 - name: A
   type: html5 
   path: pathtomoduleA
   build-parameters:
      requires:
        - name: B
          artifacts: ["*"]
          target-path: "newfolder"

 - name: B
   type: html5 
   path: pathtomoduleB

Configuring a global build

If you want to run addtional build steps before running builders of the specific modules, define it by using the build-parameters section at global level in the mta.yaml file as follows:


ID: myproject
_schema-version: '3.1'
version: 0.0.1

build-parameters:
  before-all:
    - builder: npm

modules:
 ...

You can configure any of the supported builders. Also, you can list several builders and they will run in the specified order.


ID: myproject
_schema-version: '3.1'
version: 0.0.1

build-parameters:
  before-all:
    builders:
      - builder: custom
        commands: 
          - npm run script1
      - builder: grunt


modules:
 ...

NOTE: Only the following build parameters are considered when configuring a builder at the global level:
timeout
commands (for the custom builder only)
fetcher-opts (for the fetcher builder only)

Configuring the `fetcher` builder

The fetcher builder can be used for packaging already available Maven artifacts into a multitarget application archive as the module’s build results.


- name: my_module
  build-parameters:
      builder: fetcher
      fetcher-opts:
         repo-type: maven
         repo-coordinates: mygroup:myart:1.0.0

The repo-coordinates parameter is a string of the form groupId:artifactId:version[:packaging[:classifier]].

This is equivalent to a Maven dependency command, delegating the specified coordinates to the standard Maven dependency mechanism: mvn dependency:copy -Dartifact=mygroup:myart:1.0.0

Configuring the `custom` builder

You can define your own build commands by configuring a custom builder as follows:


- name: my_module
  build-parameters:
      builder: custom
      commands:
        - npm install
        - grunt
        - npm prune --production

When used for configuring a module builder, you can leave the commands parameter list empty:


- name: my_module
  build-parameters:
      builder: custom
      commands: []

In this case, no build is performed and the module's root folder or a folder specified in the build-result is packaged into the MTA archive.

Configuring module build artifacts to package into MTA archive

You can configure the following build parameters to define artifacts to package into the MTA archive for the specific module:

Name	Default value	Description
`build-result`	For the `maven` builder: `<module's folder>/target/.war` For the `fetcher` builder: `<module's folder>/target/.*` For other builders: `<module's folder>`	A path to the build results that should be packaged.
`ignore`	None	Files and/or subfolders to exclude from the package. The provided paths should be relative to the build result folder, which can be the module's root folder (default) or the folder specified in the `build-result` parameter.

For example:


- name: module1
   type: java
   build-parameters:     
     builder: zip
     build-result: myfolder
     ignore: ["*.txt", "mtaignore/"]

# In this example, the following will not be packaged in to MTA archive:
# all files with the"txt" extension and the "mtaignore" folder within the "myfolder" directory.

NOTE: These parameters are not considered for the fetcher builder.

Configuring and packaging modules according to target platforms

If you want to control which modules should be packaged into a multitarget application archive for a specific platform, use the supported-platforms build parameter as follows:


ID: myproject
_schema-version: '2.0'
version: 0.0.1

modules:

 - name: A
   type: html5 
   path: pathtomoduleA
   build-parameters:
      supported-platforms: [NEO, CF]

 - name: B
   type: html5 
   path: pathtomoduleB
   build-parameters:
      supported-platforms: [NEO]

 - name: C
   type: html5 
   path: pathtomoduleC
   build-parameters:
      supported-platforms: []

If you build an application with the multitarget application descriptor above for a CF (Cloud Foundry) target, all its modules are built, but the resulting multitarget application archive and deployment descriptor include module A only.

If you build the same application for a NEO target, the multitarget application archive includes module A and module B.

If you have a module C with an empty supported platform list, it is never included in any multitarget application archive, regardless of the target platform of the specific multitarget application build.

If the supported-platforms build parameter is not used, the module is packaged for any target platform.

You can use these values or any combination of these values for the supported-platforms build parameter:

CF for the SAP Cloud Platform Cloud Foundry environment
NEO for the SAP Cloud Platform Neo environment
XSA for the SAP HANA XS advanced model

Configuring timeout sessions

When you build a specific module, there is a default 5-minute timeout allowance. After this time, the build will fail. You can configure the time allowed for timeout when performing a build by adding the timeout property to the module build parameters. The timeout property uses the <number of hours>h<number of minutes>m<number of seconds>s format.

For example:
```
- name: module1
   type: java
   build-parameters: 
     timeout: 6m30s
```
Also, you can use this parameter to define timeout for the global before-all build.

Configuring the build artifact name

The module build results are by default packaged into the resulting archive under the name “data”. You can change this name as needed using the build-artifact-name build parameter:
```
modules:
  - name: db
    type: hdb
    path: db
    build-parameters:
      build-artifact-name: myfileName
```
NOTE: The file extension is not configurable; it is predefined by the module type (.zip or .war).

Configuring a module that does not have source code to build and package (BETA)

There are use cases when a module does not have any source code that should be built and therefore there are no build results to be packaged into the MTA archive. The module definition in the MTA descriptor is the only input that is required to deploy the module into the target environment. You can instruct the tool to treat the module as such by setting the build parameter no-source to true as follows:
```
modules:
  - name: module1
    ...
    build-parameters:
      no-source: true
```
When the no-source parameter is true, the tool does not validate the path property, so it can be omitted as shown in the example above. No action is performed during the module's build step, so all parameters configuring the module build behaviour, e.g. builder, timeout, ignore, etc. are ignored. There is no content associated with this module in the result MTA archive. The rest of the module processing is the same as when the parameter is not provided, e.g. the entry in the generated the deployment descriptor is created based on supported-platforms settings.

Configuring a module that needs to generate SBOM content

Three native builders, npm, maven, and golang, have been upgraded to support Software Bill of Materials (SBOM) generation.

Set build-parameters.builder attribute value to npm, maven or golang:
```
modules:
  - name: node-module
  type: nodejs
  path: nodejs
  provides:
  - name: node-js_api
    properties:
        url: ${default-url}
  build-parameters:
    builder: npm
    requires:
      - name: java-module

- name: java-module
  type: java
  path: java
  properties:
    MEMORY_CALCULATOR_V1: true
  build-parameters:
    builder: maven
    requires:
      - name: go-module

- name: go-module
  type: go
  path: golang
  parameters:
    memory: 512M
    disk-quota: 256M
  properties:
    MEMORY_CALCULATOR_V1: true
  build-parameters:
    builder: golang
    requires:
      - name: custom-module

mbt build --sbom-file-path sbom-path/test.sbom.xml

or

mbt sbom-gen --sbom-file-path sbom-path/test.sbom.xml
```
For the java or nodejs module types, since their default builder is maven or npm, you do not need to set the build-parameters.builder attribute:
```
modules:
  - name: node-module
  type: nodejs
  path: nodejs
  provides:
  - name: node-js_api
    properties:
        url: ${default-url}
  build-parameters:
    requires:
      - name: java-module

- name: java-module
  type: java
  path: java
  properties:
    MEMORY_CALCULATOR_V1: true
  build-parameters:
    requires:
      - name: go-module

mbt build --sbom-file-path sbom-path/test.sbom.xml

or

mbt sbom-gen --sbom-file-path sbom-path/test.sbom.xml
```

Configuration

Overview

Configuring a builder for a module

Configuring build order

Defining module build order

Using build results for building another module

Configuring a global build

Configuring the fetcher builder

Configuring the custom builder

Configuring module build artifacts to package into MTA archive

Configuring and packaging modules according to target platforms

Configuring timeout sessions

Configuring the build artifact name

Configuring a module that does not have source code to build and package (BETA)

Configuring a module that needs to generate SBOM content

Configuring the `fetcher` builder

Configuring the `custom` builder