Skip to main content
Skip table of contents

Advanced details about Dynamic Tool Installation Mechanism

This article covers the advanced configuration details of the Dynamic tool installation within Mend Repository Integrations.

Advanced Configuration

It is not recommended to use the environment variables below unless advised by your Mend contact or experimenting in a non-production environment. These should only be used for local testing/troubleshooting and not as part of repo integrations

Name

Description

RUNINSTALL_FORCE

Optional. Installs will be performed every time, even if work has already been done in the same directory.

RUNINSTALL_ENV 

Optional. Used to distinguish different environments in the same logs

RUNINSTALL_ALWAYS_INSTALL

Optional. If this is set, installs will be done every time, even if no tool constraints have been found in the current directory.

RUNINSTALL_DEBUG

Optional. If set to true, more verbose local/console logging will be used instead of remote logging

RUNINSTALL_GITHUB_TOKEN

Optional. Configures a github.com token to allow fetching of Runinstall tool releases. Not needed in repo integration environments

Version Detection Logic

This section covers the logic behind how the Dynamic Tool Installation Mechanism defines what is the version of the tool that should be installed. Please note that this description covers the criteria at the moment of version 24.5.1 and it could have been improved since then.

Runinstall Logic

Runinstall supports the following package management tools:

  • Maven (Java)

  • Pipenv (Python)

  • Poetry (Python)

Maven

Runinstall looks for a pom.xml in the current working directory where “mvn” was called.

To detect the Java version it looks in this order:

  • Maven enforcer plugin

    • ​​executions: look for “enforce-maven” or “enforce-requirements” fields

    • If an execution is found, look in configuration-rules-requireJavaVersion

    • If a requireJavaVersion is present then use the value of “version”

  • Maven compiler plugin

    • Look inside the “configuration” object

    • Use “source” definition if found, or “release” if not found

  • Pom.xml properties

    • Look for “maven.compiler.source”

    • If not found, look for “maven.compiler.release”

    • If not found, look for “java.version”

To detect the Maven version it looks in this order:

  • Maven enforcer plugin

    • “enforce-maven” or “enforce-requirements” fields

    • Look for rules.requireMavenVersion

  • Maven compiler plugin

    • Look inside “version” field

Pipenv

Runinstall looks for a Pipfile.lock in the current working directory.

To detect the Python version it looks in this order:

  • _meta.requires.python_full_version

  • _meta.requires.python_version

Planned: Same as above but look for python_full_version or python_version within the Pipfile too.

To detect the Pipenv version it looks in the Pipfile.lock in this order:

  • default.pipenv.version

  • develop.pipenv.version

  • If _meta.requires.python_full_version exists and is 3.7.* then return “< 2023.10.20”

  • If _meta.requires.python_version exists and is 3.6.* then return “< 2022.4.20”

  • If _meta.requires.python_version exists and is 3.7.* then return “< 2022.10.9”

Poetry

Runinstall looks for pyproject.toml and poetry.lock in the current working directory.

To detect the Python version it looks in this order:

  • Looks if “python” is declared as a dependency in pyproject.toml

  • Looks for “pythonVersions” defined in poetry.lock

To detect the Poetry version it looks in this order:

  • Looks if the first line of the poetry.lock includes the Poetry version

  • Looks at the “lock-version” in the poetry.lock and maps it to Poetry versions this way:

    •   '1.0': '<1.1.0',

    •   '1.1': '<1.3.0',

    •   '2.0': '>=1.3.0 <1.4.0', // 1.4.0 introduced embedding of the poetry version in lock file header

  • Looks for “requires” in pyproject.tml

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.