Using Private Packagist in a CI/CD environment
Adding a read-only token to your organization
Documentation
- Quick Start Guide
- Private Networks and Firewalls
- Using Private Packagist in a Composer project
- API Documentation
- Security Monitoring
- Update Review
- Synchronization FAQ
- Composer Authentication
- Centralized Authentication and SSO
- Cloud Changelog
Features
- Private Composer Packages
- Mirroring Composer Packages
- GitHub, Bitbucket, GitLab and Other Integrations
- Security Monitoring
- Update Review
- Dependency License Review
- Suborganization Setup
- Vendors: Customer Setup
Articles
Private Packagist Self-Hosted
- Self-Hosted Installation
- Maintenance
- Troubleshooting Guide
- Integration Setup
- Replicated Native (deprecated)
- Self-Hosted Changelog
You can use read-only tokens to grant automated systems like continuous integration or deployment environments access to Private Packagist.
You can add read-only tokens on your organization's settings page under Authentication Tokens. Make sure to select "Read-only access to packages" on the access dropdown.
Once the token is created, you'll need to add COMPOSER_AUTH
as an environment variable in your CI/CD.
COMPOSER_AUTH='{"http-basic": {"repo.packagist.com": {"username": "token", "password": "TOKEN_HERE"}}}'
Note that read-only tokens are recommended for CI/CD where you'll be running composer install commands with an existing composer.lock file. Read-only tokens are not suitable to run composer update
as they do not create new mirrored packages. In case you have automated tasks that run package updates, make sure to use tokens with update access.
Read-only tokens don't count as users in your Private Packagist organization, while update tokens will be billed like an additional user account. Read-only tokens can only access packages in your organization. Read-only tokens created in a suborganization will only access packages in the respective suborganization.
Instructions for CI/CD services
Listed below are some examples for using Private Packagist with different CI/CD environments.
GitHub Actions
For GitHub actions, you can add the COMPOSER_AUTH
environment variable at the repository level by going to the repository settings -> secrets -> new repository secret. Environment variables can then be used in your workflow files.
If you are using shivammathur/setup-php watch out that it overwrites COMPOSER_AUTH
if you configure a COMPOSER_TOKEN
. Instead of using COMPOSER_TOKEN
you can define the entire environment variable yourself including GitHub's token:
COMPOSER_AUTH: '{"http-basic": {"repo.packagist.com": {"username": "token", "password": "${{ secrets.PACKAGIST_TOKEN }}"}}, "github-oauth": {"github.com": "${{ secrets.GITHUB_TOKEN }}"}}'
Bitbucket Pipeline
You can add the COMPOSER_AUTH
environment variable at the workspace, repository, and deployment levels on Bitbucket Pipelines as mentioned in their documentation.
Scrutinizer CI
You can add the COMPOSER_AUTH
environment variable in scrutinizer's website as mentioned in their documentation.
Start Free Trial
Login to create an organization and start your free trial!