Skip to content

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

      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.