Utilities for integrating Phylum into CI pipelines
The phylum
Python package is pip installable for the environment of your choice:
pip install phylum
It can also be installed in an isolated environment with the excellent pipx
tool:
# Globally install the app(s) on your system in an isolated virtual environment for the package
pipx install phylum
# Use the apps from the package in an ephemeral environment
pipx run --spec phylum phylum-init <options>
pipx run --spec phylum phylum-ci <options>
These installation methods require Python 3.9+ to run. For a self contained environment, consider using the Docker image as described below.
Windows binaries are offered as release artifacts for a "standalone" solution that does not require Python or Docker to run. There are two options for this installation method:
phylum-ci.zip
PATH
or reference the contained phylum-ci.exe
binary directlyphylum-ci.exe
PATH
or reference it directlyAn advantage to the self-extracting archive is that it is a single file. A disadvantage is that the file may trigger AV since it uses a packer and is not digitally signed.
Either Windows "installation" method allows access to the same phylum-ci
script entry point features.
The phylum
Python package exposes its functionality with a command line interface (CLI).
To view the options available from the CLI, print the help message from one of the scripts provided as entry points:
phylum-init -h
phylum-ci -h
The functionality can also be accessed by calling the module:
python -m phylum.init -h
python -m phylum.ci -h
The functionality is also exposed in the form of a Docker image:
# Get the `latest` tagged image
docker pull phylumio/phylum-ci
# View the help
docker run --rm phylumio/phylum-ci phylum-ci --help
# Export a Phylum token (e.g., from `phylum auth token`)
export PHYLUM_API_KEY=$(phylum auth token)
# Run it from a git repo directory containing at least one supported lockfile or manifest
docker run -it --rm -e PHYLUM_API_KEY --mount type=bind,src=$(pwd),dst=/phylum -w /phylum phylumio/phylum-ci
The default Docker image contains git
and the installed phylum
Python package.
It also contains an installed version of the Phylum CLI and all required tools needed for lockfile generation.
An advantage of using the default Docker image is that the complete environment is packaged and made available with
components that are known to work together.
One disadvantage to the default image is it's size. It can take a while to download and may provide more tools than
required for your specific use case. Special slim
tags of the phylum-ci
image are provided as an alternative.
These tags differ from the default image in that they do not contain the required tools needed for lockfile generation
(with the exception of the pip
tool). The slim
tags are significantly smaller and will allow integrations relying
on them to complete faster. They are useful for those instances where no manifest files are present and/or only
lockfiles are used.
# Get the "latest" `slim` tagged image
docker pull phylumio/phylum-ci:slim
When using the latest
tagged image, the version of the Phylum CLI is the latest
available.
There are additional image tag options available to specify a specific release of the phylum-ci
project and a specific
version of the Phylum CLI, in the form of <phylum-ci version>-CLIv<Phylum CLI version>
.
Each of these also has a -slim
variant that does not support lockfile generation. Here are image tag examples:
# Get the most current release of *both* `phylum-ci` and the Phylum CLI
docker pull phylumio/phylum-ci:latest
# Get the image with `phylum-ci` version 0.44.1 and Phylum CLI version 6.6.0
docker pull phylumio/phylum-ci:0.44.1-CLIv6.6.0
# Get the `slim` image with `phylum-ci` version 0.47.0 and Phylum CLI version 6.6.4
docker pull phylumio/phylum-ci:0.47.0-CLIv6.6.4-slim
phylum-init
Script Entry PointThe phylum-init
script can be used to fetch and install the Phylum CLI.
It will attempt to install the latest released version of the CLI but can be specified to fetch a specific version.
It will attempt to automatically determine the correct CLI release, based on the platform where the script is run, but
a specific release target can be specified.
It will accept a Phylum token from an environment variable or specified as an option, but will also function in the case
that no token is provided. This can be because there is already a token set that should continue to be used or because
no token exists and one will need to be manually created or set, after the CLI is installed.
The options for phylum-init
, automatically updated to be current for the latest release:
HINT: Click on the image to bring up the SVG file, which should allow for search and copy/paste functionality.
phylum-ci
Script Entry PointThe phylum-ci
script is for analyzing dependency file (lockfiles and manifests) changes.
The script can be used locally or from within a Continuous Integration (CI) environment.
It will attempt to detect the CI platform based on the environment from which it is run and act accordingly.
The current CI platforms/environments supported are:
Platform/Environment | Information Link |
---|---|
GitHub Actions | Documentation |
GitLab CI | Documentation |
Azure Pipelines | Documentation |
Bitbucket Pipelines | Documentation |
Jenkins Pipelines | Documentation |
Git pre-commit Hooks |
Documentation |
There is also support for local use. This is the "fall-through" case used when no other environment is detected. This can be useful to analyze dependency files locally, prior to or after submitting a pull/merge request (PR/MR) to a CI system. It can also help in establishing a successful submission prior to submitting a PR/MR to a CI system. Additionally, local use can aid troubleshooting after submitting a PR/MR to a CI system and getting unexpected results.
The options for phylum-ci
, automatically updated to be current for the latest release:
HINT: Click on the image to bring up the SVG file, which should allow for search and copy/paste functionality.
The phylum-init
script entry point will return a zero (0) exit code when it completes successfully and a one (1)
otherwise.
The phylum-ci
script entry point will return a zero (0) exit code when it completes successfully or one of the
following non-zero codes otherwise:
Exit Code | Meaning |
---|---|
1 | Default failure code. An unrecoverable error was encountered. |
2 | Phylum analysis is complete and contains a policy violation. |
6 | Phylum analysis is incomplete and contains a policy violation. |
10 | Dependency file(s) failed filtering and excluded from analysis. See this FAQ for more. |
11 | No dependency files were provided or detected. |
20 | A manifest is attempted to be parsed but lockfile generation has been disabled. |
Copyright (C) 2022 Phylum, Inc.
This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License or any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program.
If not, see https://www.gnu.org/licenses/gpl.html or write to phylum@phylum.io
or engineering@phylum.io
Suggestions and help are welcome. Feel free to open an issue or otherwise contribute. More information is available on the contributing documentation page.
Everyone participating in the phylum-ci
project, and in particular in the issue tracker and pull requests, is
expected to treat other people with respect and more generally to follow the guidelines articulated in the
Code of Conduct.
Found a security issue in this repository? See the security policy for details on coordinated disclosure.
All notable changes to this project are documented in the CHANGELOG.
The format of the change log is based on Keep a Changelog, and this project adheres to Semantic Versioning. The entries in the changelog are primarily automatically generated through the use of conventional commits and the Python Semantic Release tool. However, some entries may be manually edited, where it helps for clarity and understanding.