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