Supported dependency managers

NPM

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

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

Your project must contains the following files:

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

Private NPM packages

To provide access to private packages you need to use the following:

  ...
  "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"
        }
      ]
    }
  }

More details how it works.

Yarn

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

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

Your project must contains the following files:

  • package.json
  • yarn.lock

Private Yarn packages

Use the same like for npm.

Composer

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

Your project must contains the following files:

  • composer.json
  • composer.lock

The section extra in configs file is available for Composer projects:

{
  ...
  "extra": {
    "use_no_scripts_mode": "yes"
  }
}

By default, Codario uses "no-scripts" mode for every composer process (skips execution of scripts defined in composer.json). This is the preferred way to process a project in Codario, but sometimes it broke important features: f.e. if you use cweagans/composer-patches package to provide patches, in this case, "no-scripts" mode disables checking to compatibility your patches and new updates and in result, Codario providing new updates without checking to compatibility with your patches. We recommend disabling "no-scripts" for this and similar cases.

The specified behavior above can be override using property use_no_scripts_mode can be equal to yes (by default) or no.

Private Composer packages

To provide access to private packages you need to use the following:

  ...
  "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:

Details about "http-basic".

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 contains the following files:

  • requirements.txt

Pip projects don't have manifest file (with constraints of versions for packages) and to avoid any uncompatibilities Codario will not update major versions for projects (only minor and patch).

pipenv project

Your project must contains 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"

You can store secret data (like authorization token) directly in these files, but it's very bad practice.

To avoid problems with the security of your data Codario supports to use environment variables for Python projects by the following way:

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

More details for pip and pipenv.

Drupal

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

The section extra in configs file is available for Drupal projects:

{
  "integrations": {
   ...
  },
  "update_behavior": {
   ...
  },
  "events": {
   ...
  },
  "extra": {
    "min_security_level": "Moderately Critical"
  }

Possible to apply only updates equal or high than some value from Drupal Security Score, specify extra.min_security_level property (not required, Not Critical by default). This will work only for Drupal modules and will not affect other packages.

Available values for min_security_level property:

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

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

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).

The section extra in configs file is available for Dockerfile projects:

{
  "integrations": {
   ...
  },
  "update_behavior": {
   ...
  },
  "events": {
   ...
  },
  "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 with Dockerfile name inside 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 be updated only 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.
  • minor — will be updated minor and patch section up to latest available version.
  • major — will be updated major, minor and patch sections 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. Independent on "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 isn't supporting.