This Docker image for BitBucket Pipelines allows users to build Servoy WAR files, using options from Servoy's bundled WAR export. In order to use this Action, you will need an All Products Pack API key from Servoy Components.

See the LICENSE for more information on the dual licensing for commercial projects.

Examples

To view a full example project, including the workflow file, please see our examples repo.

Build the WAR

image: atlassian/default-image:3

options:
  size: 2x

definitions:
  services:
    docker:
      memory: 7168
  steps:
    - step: &war-build
        name: WAR Build
        script:
          - pipe: docker://itechpros/servoy-war-builder:0.4.8
            variables:
              SERVOY_VERSION: 2023.03.2.3844
              API_KEY: ${SERVOY_COMPONENTS_API_KEY}
              SOLUTION_NAME: MySolution
              DEFAULT_ADMIN_USER: ${SERVOY_DEFAULT_ADMIN_USER}
              DEFAULT_ADMIN_PASSWORD: ${SERVOY_DEFAULT_ADMIN_PASSWORD}
              PROPERTIES_FILE: prop_files/servoy.build.properties
pipelines:
  default:
   - step: *war-build

WAR + Upload to BitBucket Downloads

You will need to follow the setup instructions for this integration.

image: atlassian/default-image:3

options:
  size: 2x

definitions:
  services:
    docker:
      memory: 7168
  steps:
    - step: &war-build
        name: WAR Build
        script:
          - pipe: docker://itechpros/servoy-war-builder:0.4.8
            variables:
              SERVOY_VERSION: 2023.03.2.3844
              API_KEY: ${SERVOY_COMPONENTS_API_KEY}
              SOLUTION_NAME: MySolution
              DEFAULT_ADMIN_USER: ${SERVOY_DEFAULT_ADMIN_USER}
              DEFAULT_ADMIN_PASSWORD: ${SERVOY_DEFAULT_ADMIN_PASSWORD}
              PROPERTIES_FILE: prop_files/servoy.build.properties
          - pipe: atlassian/bitbucket-upload-file:0.1.2
            variables:
              BITBUCKET_USERNAME: $BITBUCKET_USERNAME
              BITBUCKET_APP_PASSWORD: $BITBUCKET_APP_PASSWORD
              FILENAME: "MySolution.war"
pipelines:
  default:
   - step: *war-build

WAR + S3 Upload

You will need to follow the setup instructions for this integration.

image: atlassian/default-image:3

options:
  size: 2x

definitions:
  services:
    docker:
      memory: 7168
  steps:
    - step: &war-build
        name: WAR Build
        script:
          - pipe: docker://itechpros/servoy-war-builder:0.4.8
            variables:
              SERVOY_VERSION: 2023.03.2.3844
              API_KEY: ${SERVOY_COMPONENTS_API_KEY}
              SOLUTION_NAME: MySolution
              DEFAULT_ADMIN_USER: ${SERVOY_DEFAULT_ADMIN_USER}
              DEFAULT_ADMIN_PASSWORD: ${SERVOY_DEFAULT_ADMIN_PASSWORD}
              PROPERTIES_FILE: prop_files/servoy.build.properties
          - pipe: atlassian/aws-s3-deploy:0.3.8
            variables:
              AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID
              AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY
              AWS_DEFAULT_REGION: 'us-east-1'
              S3_BUCKET: 'bbci-example-s3-deploy'
              LOCAL_PATH: 'MySolution.war'
              ACL: 'public-read'
pipelines:
  default:
   - step: *war-build

WAR + Azure Upload

You will need to follow the setup instructions for this integration.

image: atlassian/default-image:3

options:
  size: 2x

definitions:
  services:
    docker:
      memory: 7168
  steps:
    - step: &war-build
        name: WAR Build
        script:
          - pipe: docker://itechpros/servoy-war-builder:0.4.8
            variables:
              SERVOY_VERSION: 2023.03.2.3844
              API_KEY: ${SERVOY_COMPONENTS_API_KEY}
              SOLUTION_NAME: MySolution
              DEFAULT_ADMIN_USER: ${SERVOY_DEFAULT_ADMIN_USER}
              DEFAULT_ADMIN_PASSWORD: ${SERVOY_DEFAULT_ADMIN_PASSWORD}
              PROPERTIES_FILE: prop_files/servoy.build.properties
          - pipe: microsoft/azure-cli-run:1.0.0
            variables:
              AZURE_APP_ID: $AZURE_APP_ID
              AZURE_PASSWORD: $AZURE_PASSWORD
              AZURE_TENANT_ID: $AZURE_TENANT_ID
              CLI_COMMAND: 'az storage blob upload --file MySolution.war --container-name $containerName --account-name $storageAccount --auth-mode login'
pipelines:
  default:
   - step: *war-build

WAR + SFTP Upload

image: atlassian/default-image:3

options:
  size: 2x

definitions:
  services:
    docker:
      memory: 7168
  steps:
    - step: &war-build
        name: WAR Build
        script:
          - pipe: docker://itechpros/servoy-war-builder:0.4.8
            variables:
              SERVOY_VERSION: 2023.03.2.3844
              API_KEY: ${SERVOY_COMPONENTS_API_KEY}
              SOLUTION_NAME: MySolution
              DEFAULT_ADMIN_USER: ${SERVOY_DEFAULT_ADMIN_USER}
              DEFAULT_ADMIN_PASSWORD: ${SERVOY_DEFAULT_ADMIN_PASSWORD}
              PROPERTIES_FILE: prop_files/servoy.build.properties
          - pipe: atlassian/sftp-deploy:0.8.0
            variables:
              USER: ${FTP_USER}
              PASSWORD: ${FTP_PASSWORD}
              SERVER: ${FTP_SERVER}
              REMOTE_PATH: '/my/remote/path'
              LOCAL_PATH: 'MySolution.war'
              EXTRA_ARGS: '-o VerifyHostKeyDNS=yes -o StrictHostKeyChecking=no'
pipelines:
  default:
   - step: *war-build

WAR + Auto Deploy

Coming soon!

Options

• SERVOY_VERSION 🔴 required
  The full Servoy version to use for the build. To see a list of supported versions, please view the "Supported Servoy Versions" section of this document.
  NOTE: If you're using a version of Servoy that does not come with a bundled Java version, please be sure to use at least version 0.3.2 of the pipe.
• API_KEY 🔴 required
  All Products Pack API key obtained from the Servoy Components website. We recommend putting this value in BitBucket Repository Secrets to prevent accidental exposure through the BitBucket Pipeline logs, or from unauthorized users.
• SOLUTION_NAME 🔴 required
  Name of the primary solution to export to the WAR file.
  WAR export flag: -s
• DEFAULT_ADMIN_USER 🔴 required
  Default admin username to include in the WAR file. We recommend putting this value in BitBucket Repository Secrets to prevent accidental exposure through the BitBucket Pipeline logs, or from unauthorized users.
  WAR export flag: -defaultAdminUser
• DEFAULT_ADMIN_PASSWORD 🔴 required
  Default admin password to include in the WAR file. We recommend putting this value in BitBucket Repository Secrets to prevent accidental exposure through the BitBucket Pipeline logs, or from unauthorized users.
  WAR export flag: -defaultAdminPassword
• PROPERTIES_FILE 🔴 required
  Path and name of the properties file used to start the exporter. Path should be relative to the root directory of your GitHub repository.
  WAR export flag: -p
  Examples:

variables:  
  # ...
  PROPERTIES_FILE: servoy.war.properties        # Use the servoy.war.properties file in the root directory of the repository
  PROPERTIES_FILE: mydir/servoy.war.properties  # Use the servoy.war.properties file in the "mydir" directory of the repository

• IGNORE_BUILD_ERRORS
  Ignores build errors 🟡 (warning: use of this flag is discouraged; it can cause invalid solutions to be exported)
  WAR export flag: -ie
  Default: false
  Examples:

  variables:
    # ...
    IGNORE_BUILD_ERRORS: true   # Ignore build errors
    IGNORE_BUILD_ERRORS: false  # Don't ignore build errors (default)

• SKIP_BUILD
  No build markers will be generated. This can greatly decrease export time 🟡 (warning: use of this flag is discouraged; it can cause invalid solutions to be exported)
  WAR export flag: -sb
  Default: false Examples:

  variables:
    # ...
    SKIP_BUILD: true   # Don't generate build markers.
    SKIP_BUILD: false  # Generate build markers (default)

• DBI
  Export based on DBI files (even if database servers are available).
  WAR export flag: -dbi
  Default: false
  Examples:

  variables:
    # ...
    DBI: true   # Export based on DBI files
    DBI: false  # Don't export based on DBI files (default)

• PROPERTIES_FILE_WAR
  Path and name of the properties file to be included in the WAR. Path should be relative to the root directory of your GitHub repository. If a WAR property file is not supplied, we will use the property file specified in properties-file.
  WAR export flag: -pfw
  Examples:

  variables:
    # ...
    PROPERTIES_FILE_WAR: servoy.war.properties        # Use the servoy.war.properties file in the root directory of the repository
    PROPERTIES_FILE_WAR: mydir/servoy.war.properties  # Use the servoy.war.properties file in the "mydir" directory of the repository

• BEANS
  Space separated list of (smart/web client) beans to export
  WAR export flag: -b
  Default: all beans are exported
  Examples:

  variables:
    # ...
    BEANS: bean1.jar bean2.zip  # Include bean1.jar and bean2.zip in the export
    BEANS: <none>               # Don't include any beans in the export

• EXCLUDE_BEANS
  Space separated list of beans to be excluded from the export
  WAR export flag: -excludeBeans
  Examples:

  variables:
    # ...
    EXCLUDE_BEANS: bean1.jar bean2.zip  # Don't include bean1.jar and bean2.zip in the export

• LAFS
  Space separated list of look-and-feels (smart client) to export
  WAR export flag: -l
  Default: all lafs are exported Examples:

  variables:
    # ...
    LAFS: laf1 laf2  # Include laf1 and laf2 in the export
    LAFS: <none>     # Don't include any lafs in the export

• EXCLUDE_LAFS
  Space separated list of look-and-feels to be excluded from the export
  WAR export flag: -excludeLafs
  Examples:

  variables:
    # ...
    EXCLUDE_LAFS: laf1 laf2  # Exclude laf1 and laf2 from the export

• DRIVERS
  Space separated list of JDBC (database) drivers to export
  WAR export flag: -d
  Default: all drivers are exported
  Examples:

  variables:
    # ...
    DRIVERS: driver1.jar driver2.jar  # Include driver1.jar and driver2.jar in the export
    DRIVERS: <none>                   # Don't include any drivers in the export

• EXCLUDE_DRIVERS
  Space separated list of drivers to be excluded from the export
  WAR export flag: -excludeDrivers
  Examples:

  variables:
    # ...
    EXCLUDE_DRIVERS: driver1.jar driver2.jar  # Exclude driver1.jar and driver2.jar from the export

• PLUGINS
  Space separated list of plugins to export
  WAR export flag: -pi
  Default: all plugins are exported

  variables:
    # ...
    PLUGINS: plugin1.jar plugin2.jar  # Include plugin1.jar and plugin2.jar in the export
    PLUGINS: <none>                   # Don't include any plugins in the export

• EXCLUDE_PLUGINS
  Space separated list of plugins to be excluded from the export
  WAR export flag: -excludePlugins
  Examples:

  variables:
    # ...
    EXCLUDE_PLUGINS: plugin1.jar plugin2.jar  # Don't include plugin1.jar and plugin2.jar in the export

• COMPONENTS
  Space separated list of components to export
  WAR export flag: -crefs
  Default: all
  Examples:

  variables:
    # ...
    COMPONENTS: component1 component2  # Include component1 and component2 in the export
    COMPONENTS: all                    # Include all components in the export (default)

• EXCLUDE_COMPONENTS
  Space separated list of components to be excluded from the export
  WAR export flag: -excludeComponentPkgs
  Examples:

  variables:
    # ...
    EXCLUDE_COMPONENTS: component1 component2  # Exclude component1 and component2 from the export

• SERVICES
  Space separated list of services to export
  WAR export flag: -srefs
  Default: all
  Examples:

  variables:
    # ...
    SERVICES: service1 service2  # Include service1 and service2 in the export
    SERVICES: all                # Include all services in the export (default)

• EXCLUDE_SERVICES
  Space separated list of services to be excluded from the export
  WAR export flag: -excludeServicePkgs
  Examples:

  variables:
    # ...
    EXCLUDE_SERVICES: service1 service2  # Exclude service1 and service2 from the export

• ADDITIONAL_SOLUTIONS
  Space separated list of solutions that must be exported, but are not in the current solution's modules (for example, solutions for batch processors)
  WAR export flag: -nas
  Examples:

  variables:
    # ...
    ADDITIONAL_SOLUTIONS: mod_batch_processor mod_rest_api  # Includes solutions "mod_batch_exporter" and "mod_rest_api" in the export, even if the primary solution doesn't include them as dependencies

• EXPORT_METADATA
  Export metadata tables
  WAR export flag: -md
  Default: false
  Examples:

  variables:
    # ...
    EXPORT_METADATA: true   # Include metadata in the export
    EXPORT_METADATA: false  # Don't include metadata in the export (default)

• CHECK_METADATA
  Check that metadata for metadata tables is the same for each table, both in the according workspace file and in the actual table in the database before exporting
  WAR export flag: -checkmd
  Default: false

  variables:
    # ...
    CHECK_METADATA: true   # Verify metadata
    CHECK_METADATA: false  # Don't verify metadata (default)

• SAMPLE_DATA
  Export sample data
  WAR export flag: -sd
  Default: false
  Examples:

  variables:
    # ...
    SAMPLE_DATA: true   # Export sample data
    SAMPLE_DATA: false  # Don't export sample data (default)

• SAMPLE_DATA_ROW_COUNT
  Number of rows of sample data to export per table
  WAR export flag: -sdcount
  Examples:

  variables:
    # ...
    SAMPLE_DATA_ROW_COUNT: 50  # Include 50 rows of sample data per table in the export

• I18N
  Export i18n data
  WAR export flag: -i18n
  Default: false
  Examples:

  variables:
    # ...
    I18N: true   # Include i18n data in the export
    I18N: false  # Don't include i18n data in the export (default)

• USERS
  Exports users
  WAR export flag: -users
  Default: false
  Examples:

  variables:
    # ...
    USERS: true   # Include users in the export
    USERS: false  # Don't include users in the export

• TABLES
  Export all table information about tables from referenced servers
  WAR export flag: -tables
  Default: false
  Examples:

  variables:
    # ...
    TABLES: true   # Include table information from referenced servers in the export
    TABLES: false  # Don't include table information from referenced servers in the export (default)

• WAR_FILE_NAME
  The name of the WAR file
  WAR export flag: -warFileName
  Examples:

  variables:
    # ...
    WAR_FILE_NAME: MyFile.war  # Exports the WAR file to MyFile.war, instead of <primary solution name>.war

• OVERWRITE_GROUPS
  Overwrites groups
  WAR export flag: -overwriteGroups
  Default: false
  Examples:

  variables:
    # ...
    OVERWRITE_GROUPS: true   # Overwrites groups
    OVERWRITE_GROUPS: false  # Doesn't overwrite groups (default)

• ALLOW_SQL_KEYWORDS
  Allows SQL keywords
  WAR export flag: -allowSQLKeywords
  Default: false
  Examples:

  variables:
    # ...
    ALLOW_SQL_KEYWORDS: true   # Allows table/column names that are reserved SQL keywords
    ALLOW_SQL_KEYWORDS: false  # Doesn't allow table/column names that are reserved SQL keywords (default)

• STOP_ON_DATA_MODEL_CHANGES
  Stops import if the data model changes
  WAR export flag: -stopOnDataModelChanges
  Default: false
  Examples:

  variables:
    # ...
    STOP_ON_DATA_MODEL_CHANGES: true   # Stops the import if it results in a data model change
    STOP_ON_DATA_MODEL_CHANGES: false  # Don't stop the import if it results in a data model change (default)

• ALLOW_DATA_MODEL_CHANGES
  A space separated list of server names that allow data model changes. If the value is "all", then data model changes are allowed on all servers
  WAR export flag: -allowDataModelChanges
  Examples:

  variables:
    # ...
    ALLOW_DATA_MODEL_CHANGES: server1 server2  # Allow data model changes only on the server1 and server2 database servers
    ALLOW_DATA_MODEL_CHANGES: all              # Allow data model changes on all servers

• SKIP_DATABASE_VIEWS_UPDATE
  Skips database views update
  WAR export flag: -skipDatabaseViewsUpdate
  Default: false
  Examples:

  variables:
    # ...
    SKIP_DATABASE_VIEWS_UPDATE: true   # Skips updating database views
    SKIP_DATABASE_VIEWS_UPDATE: false  # Doesn't skip updating database views (default)

• OVERRIDE_SEQUENCE_TYPES
  Overrides sequence types
  WAR export flag: -overrideSequenceTypes
  Default: false
  Examples:

  variables:
    OVERRIDE_SEQUENCE_TYPES: true   # Overrides the sequence types in the Servoy repository database with the sequence types in the export
    OVERRIDE_SEQUENCE_TYPES: false  # Doesn't override the sequence types in the Servoy repository database (default)

• OVERRIDE_DEFAULT_VALUES
  Overrides default values
  WAR export flag: -overrideDefaultValues
  Default: false
  Examples:

  variables:
    # ...
    OVERRIDE_DEFAULT_VALUES: true   # Overrides the column default values in the Servoy repository database with the default values in the export
    OVERRIDE_DEFAULT_VALUES: false  # Doesn't override the default values in the Servoy repository database (default)

• INSERT_NEW_I18N_KEYS_ONLY
  Inserts new i18n keys only
  WAR export flag: -insertNewI18NKeysOnly
  Default: false
  Examples:

  variables:
    # ...
    INSERT_NEW_I18N_KEYS_ONLY: true   # Only inserts new (doesn't update existing) i18n keys
    INSERT_NEW_I18N_KEYS_ONLY: false  # i18n keys are inserted and updated based on the export (default)

• IMPORT_USER_POLICY
  0 = don't
  1 = create users & update groups
  2 = overwrite completely
  WAR export flag: -importUserPolicy
  Examples:

  variables:
    # ...
    IMPORT_USER_POLICY: 0  # Don't import any users
    IMPORT_USER_POLICY: 1  # Create users & update groups (don't update existing users) (default)
    IMPORT_USER_POLICY: 2  # Overwrite users based on the export

• ADD_USERS_TO_ADMIN_GROUP
  Adds users to admin group
  WAR export flag: -addUsersToAdminGroup
  Default: false
  Examples:

  variables:
    # ...
    ADD_USERS_TO_ADMIN_GROUP: true   # Adds users to admin group
    ADD_USERS_TO_ADMIN_GROUP: false  # Doesn't add users to admin group (default)

• UPDATE_SEQUENCES
  Updates sequences
  WAR export flag: -updateSequences
  Default: false Examples:

  variables:
    # ...
    UPDATE_SEQUENCES: true   # Updates Servoy sequences when the WAR is imported
    UPDATE_SEQUENCES: false  # Doesn't update Servoy sequences when the WAR is imported (default)

• UPGRADE_REPOSITORY
  Automatically upgrade repository if needed
  WAR export flag: -upgradeRepository
  Default: false
  Examples:

  variables:
    # ...
    UPGRADE_REPOSITORY: true   # Upgrades the Servoy repository (if needed)
    UPGRADE_REPOSITORY: false  # Doesn't upgrade the Servoy repository (default)

• CONTEXT_FILE_NAME
  Path to a Tomcat context.xml that should be included into the WAR/META-INF/context.xml. Path should be relative to the root directory of your GitHub repository.
  WAR export flag: -contextFileName
  Examples:

  variables:
    # ...
    CONTEXT_FILE_NAME: context.xml        # Use the context.xml file in the root directory of the repository
    CONTEXT_FILE_NAME: mydir/context.xml  # Use the context.xml file in the "mydir" directory of the repository

• USE_AS_REAL_ADMIN_USER
  The default user login will be available as a normal admin user in the solutions as well
  WAR export flag: -useAsRealAdminUser
  Default: false
  Examples:

  variables:
    # ...
    USE_AS_REAL_ADMIN_USER: true   # The default admin user will be treated as a normal admin user in the solutions
    USE_AS_REAL_ADMIN_USER: false  # THe default admin user will not be treated as a normal admin user in the solutions (default)

• DO_NOT_OVERWRITE_DB_SERVER_PROPERTIES
  SKIP overwrite of old DB server properties
  WAR export flag: -doNotOverwriteDBServerProperties
  Default: false
  Examples:

  variables:
    # ...
    DO_NOT_OVERWRITE_DB_SERVER_PROPERTIES: true   # Doesn't overwrite DB server properties on import
    DO_NOT_OVERWRITE_DB_SERVER_PROPERTIES: false  # Allows DB server properties to be overwritten (default)

• OVERWRITE_ALL_PROPERTIES
  Overwrite all (potentially changed via admin page) properties of a previously deployed WAR application with the values from the servoy.properties of this WAR export
  WAR export flag: -overwriteAllProperties
  Default: false
  Examples:

  variables:
    # ...
    OVERWRITE_ALL_PROPERTIES: Overwrite all Servoy server properties based on the properties file included in this import
    OVERWRITE_ALL_PROPERTIES: Don't overwrite any Servoy server properties (default)

• LOG4J_CONFIGURATION_FILE
  A path to a Log4J configuration file that should be included instead of the default one. Path should be relative to the root directory of your GitHub repository.
  WAR export flag: -log4jConfigurationFile
  Examples:

  variables:
    # ...
    LOG4J_CONFIGURATION_FILE: log4j.xml        # Use the log4j.xml file in the root directory of the repository
    LOG4J_CONFIGURATION_FILE: mydir/log4j.xml  # Use the log4j.xml file in the "mydir" directory of the repository

• WEB_XML_FILE_NAME
  A path to a web.xml that should be included instead of the default one. Path should be relative to the root directory of your GitHub repository.
  WAR export flag: -webXmlFileName
  Examples:

  variables:
    # ...
    WEB_XML_FILE_NAME: web.xml        # Use the web.xml file in the root directory of the repository
    WEB_XML_FILE_NAME: mydir/web.xml  # Use the web.xml file in the "mydir" directory of the repository

• NG2
  Export Titanium NG2 binaries. If 'sourcemaps' is given, sourcemaps will be generated for .ts files - useful for debugging WAR export flag: -ng2
  Examples:

  variables:
    # ...
    NG2: true        # Export NG2 resources
    NG2: false       # Don't export NG2 resources
    NG2: sourcemaps  # Export sourcemaps along with NG2 resources

• NG1
  Export NG1 client resources
  WAR export flag: -ng1
  Default: false

  variables:
    # ...
    NG1: true   # Export NG1 resources
    NG1: false  # Don't export NG1 resources (default)

• LICENSES
  Space delimited licenses to include in the WAR file. Format should be ' '. If you have multiple licenses, use multiple lines. We recommend putting the Servoy license value in GitHub Action Secrets to prevent accidental exposure through the GitHub Action logs, or from unauthorized users.
  Examples:

  variables:
    # ...
    LICENSES: "Servoy Components" ${{ secrets.SERVOY_LICENSE}} SERVER   # Use a single license in the export
    LICENSES: |                                                         # Use multiple licenses in the export
      "Servoy Components" ${{ secrets.SERVOY_COMPONENTS_LICENSE }} SERVER
      "My Other Company" ${{ secrets.MY_OTHER_COMPANY_LICENSE }} 1000

• EXTRAS_FOLDER
  Path to the extras folder that contains additional plugins, drivers, etc. that should be included in the Servoy install. Path should be relative to the root directory of your GitHub repository. This folder should contain a sub-folder named "application_server".
  Examples:

  variables:
    # ...
    EXTRAS_FOLDER: ServoyDeveloperExtras  # Use the plugins, drivers, etc. in ServoyDeveloperExtras/application_server in our export

• TIMEOUT
  
  Number of milliseconds to allow the build process to run before terminating it. Defaults to 30 minutes.
  
  Examples:
  

  variables:
    # ...
    TIMEOUT: 600000   # 10 minute timeout
    TIMEOUT: 1800000  # 30 minute timeout
    TIMEOUT: 3600000  # 1 hour timeout
  

• POST_WAR_EXTRAS_FOLDER
  Path to the extras folder that contains files that should be copied into the WAR after it's built. Path should be relative to the root directory of your BitBucket repository. NOTE: This option is only available in version 0.2.0 or higher.
  Examples:
  variables:
  # ...
  POST_WAR_EXTRAS_FOLDER: PostWarExtras  # Include the files & folders in PostWarExtras/ in our WAR
• BUILD_MAX_MEMORY
  Maximum amount of memory that can be consumed by the build process (default 2 GB). NOTE: This option is only available in version 0.3.0 or higher.
  Examples:
  variables:
  # ...
  BUILD_MAX_MEMORY: 2048m  # Limit the WAR builds to 2 GB of memory
  BUILD_MAX_MEMORY: 4096m  # Limit the WAR builds to 4 GB of memory