Skip to content

Supported dependency managers

NPM

The sandbox for npm-based projects has NodeJS 14.17.6 engine.

For checking of security state for packages we use official Security Advisories.

Your project must contain the following files:

  • package.json
  • npm-shrinkwrap.json or package-lock.json

Private NPM packages

To provide access to private packages you have to add the following information to the extra section in the project's configuration (see npm docs for more details):

  ...
  "extra": {
    "private_data": {
      "registries": [
        {
          "registry": "registry.npmjs.org",
          "npm_token": "00000000-0000-0000-0000-000000000000"
        },
        ...
        {
          "registry": "registry.npmjs.org",
          "npm_token": "00000000-0000-0000-0000-000000000000"
        }
      ]
    }
  }

Yarn

The sandbox for yarn-based projects has NodeJS 14.17.6 engine and Yarn 1.16.0.

For checking of security state for packages we use official npm Security Advisories.

Your project must contain the following files:

  • package.json
  • yarn.lock

Private Yarn packages

Use the same as for npm.

Composer

The sandbox for composer-based projects has PHP 8.1 core.

Your project must contain the following files:

  • composer.json
  • composer.lock

By default, Codario uses --no-scripts and --ignore-platform-reqs arguments for every composer process.

This is the preferred way to process a project in Codario, but sometimes it broke important features: For example, if you use cweagans/composer-patches package to provide patches, "no-scripts" mode disables checking the compatibility of your patches and new updates and, in result, Codario would provide new updates without checking the compatibility with your patches. Hence, we recommend disabling "no-scripts" for this and similar cases.

In the case when the manifest file contains config.platform.php property, then Codario will respect it and use only --ignore-platform-req=lib-* --ignore-platform-req=ext-* --ignore-platform-req=hhvm instead of --ignore-platform-reqs.

If for some reason you want to disable --ignore-platform-reqs in general - just disable that mode in project configs.

The specified behavior above can be overridden by setting use_no_scripts_mode / use_ignore_platform_reqs to yes (by default) or no:

By default, Codario uses "Composer 2" to handle every composer process. If you need to use "Composer 1" for any reason just specify 1 in "composer_version" property.

{
  ...
  "extra": {
    "use_no_scripts_mode": "yes",
    "use_ignore_platform_reqs": "yes",
    "composer_version": "1"
  }
}

Private Composer packages

To provide access to private packages you have to add the following information to the extra section in the project's configuration:

  ...
  "extra": {
    "private_data": {
      "http-basic": [
        {
          "host": "registry.composer.org",
          "username": "username",
          "password": "password"
        },
        ...
        {
          "host": "registry.composer.org",
          "username": "username",
          "password": "password"
        }
      ],
      "bitbucket-oauth": [
        {
          "host": "bitbucket.org",
          "consumer-key": "key",
          "consumer-secret": "secret"
        }
      ],
      "gitlab-token": [
        {
          "host": "gitlab.com",
          "token": "privatetoken"
        }
      ],
      "gitlab-oauth": [
        {
          "host": "gitlab.com",
          "token": "oauthtoken"
        }
      ],
      "github-oauth": [
        {
          "host": "github.com",
          "token": "oauthtoken"
        }
      ]
    }
  }

Read more about:

Python

The Docker image for python-based (pip, pipenv) projects has Python 3.6, pipenv 2018.11.26 and pip 19.2.2.

pip project

Your project must contain requirements.txt file.

Pip projects do not have manifest files (with constraints of versions for packages). Hence, to avoid any incompatibilities, Codario will not update major versions for projects (only minor and patch).

pipenv project

Your project must contain the following files:

  • Pipfile
  • Pipfile.lock

Private Python packages

To use private sources in pip project, you need place the following in requirements.txt:

--extra-index-url https://${USERNAME}:${AUTH_TOKEN}@pypi.registry.org/simple

To use private sources in pipenv project, you need place the following in Pipfile:

[[source]]
url = "https://${USERNAME}:${AUTH_TOKEN}@pypi.registry.org/simple"
verify_ssl = true
name = "pypi-registry"

To avoid problems with the security of your data, Codario supports to use environment variables for Python projects by adding the following information to the extra section in the project's configuration:

  ...
  "extra": {
    "private_data": {
      "environment": {
        "USERNAME": "token",
        "AUTH_TOKEN": "token",
        ...,
        "VARIABLE_N": "value"
      }
    }
  }

More details for pip and pipenv.

Java

The Docker image for java-based (maven, gradle) projects has OpenJDK 11.0.4.

Maven

Your project must contain pom.xml file.

Gradle

Your project must contain build.gradle or build.gradle.kts file.

Extra configs for Java-based projects

To configure the project, you have to add the following information to the extra section in the project's configuration:

{
  ...
  "extra": {
    "update_policy": "minor"
  }
}

You can specify "update policy" for your project in extra.update_policy property.

Available values for "update policy":

  • minor: Will keep a major version for dependencies and update up to latest available version respects a current major version (behavior by default).
  • major: Will update dependencies up to latest available version.

Drupal

Original security advices from drupal.org are available for any type of Drupal projects (including Drupal severity score).

To apply the special update behaviors for specific values from Drupal Security Score, add the following lines to the update_behavior.updates section in the project's configuration (not required):

{
  ...
  "update_behavior": {
    "updates": {
      ...
      "vulnerable:FROM_LEVEL..TO_LEVEL": {
        "source_branch": "dev",
        "destination_branch": "updates/[task:id]",
        "auto_start_updates": "no",
        "skip_manual_testing": "no"
      }
    }
    ...
  }

This will work only for Drupal modules and will not affect other packages.

Available values for FROM_LEVEL / TO_LEVEL properties:

  • Not Critical
  • Less Critical
  • Moderately Critical
  • Critical
  • Highly Critical

So, the name of the update type section must look like vulnerable:Moderately Critical..Highly Critical, that section will describe the special update behavior for a task containing at least one package with "security risk" equal or higher than "Moderately Critical".

If an update task contains several packages with vulnerable packages, Codario will use the "update type" of the package with highest "security score".

The use_no_scripts_mode extra-property is available as well, see how it works in Composer paragraph above.

Allowed usage of extra values for "only_when" property: 

{
  ...
  "action": {
    ...
    "only_when": "task:contains_vulnerable_packages:min_security_level:MIN_SECURITY_LEVEL AND task:contains_vulnerable_packages:max_security_level:MAX_SECURITY_LEVEL"
  }

MIN_SECURITY_LEVEL / MAX_SECURITY_LEVEL - can be any value from the list above. Allowed combining the conditions via AND operator.

Based on composer

Codario supports Drupal 7+ projects based on composer.

Based on stored modules

Codario supports Drupal 7 projects with Core and Modules which stored directly in a repository.

Private Drupal packages

For "composer-based" use the same as for composer, for "stored-modules-based" isn't supported.

Dockerfile

Codario can monitor and provide updates for your Dockerfile (not for built Docker images).

To configure the project, you have to add the following information to the extra section in the project's configuration:

{
  ...
  "extra": {
    "update_policy": "patch",
    "dockerfiles" : [
      "Dockerfile.prod",
      "Dockerfile.stage"
    ],
    "policies": {
      "images": {
        "mongo": "patch",
        "redis": "minor",
      },
      "files": {
        "app1/Dockerfile": {
         "mongo": "minor",
        }
      }
    }
  }
}

Codario will monitor and provide updates for all files named Dockerfile inside the specified "root folder" for a project.

If you are using some specific names for your Dockerfiles, you can specify them in extra.dockerfiles section and Codario will monitor them as well. In example above Codario will monitor Dockerfile, Dockerfile.prod and Dockerfile.stage.

Codario can monitor and provide updates only for:

  • Public images from hub.docker.com.
  • Images, which are using major.minor.patch or major.minor in tags for defining of version.

You can specify "update policy" for your project in extra.update_policy property.

Available values for "update policy":

  • none: Updates will not be applied.
  • patch: Will update patch section up to latest available version. For a case when an image has a tag in format major.minor, will be used "major" policy (behavior by default).
  • minor: Will update minor and patch section up to latest available version.
  • major: Will update major, minor, and patch section up to latest available version.

You can customize specific "update policy" for every image in extra.policies.images section.

You can customize specific "update policy" for every image inside a specific Dockerfile in extra.policies.files section as well. Independently of the "root folder" property, you should specify a full path from "root" of your repository.

Private Dockerfile repositories

Codario analyzes only public repositories on hub.docker.com and authorization is not supported yet.