CI/CD overview

A CI/CD job reaches CloudRepo the way a laptop does: the build tool sends a repository token with each request. What a pipeline adds is the question of where the token lives. The answer is the same on every platform: in the platform’s secret store, handed to the job as an environment variable, and read by a committed config file or a command that names the variable.

Pick your platform

Platform	Where the secret lives	Guide
GitHub Actions	Repository Settings, Secrets and variables, Actions	Publish from GitHub Actions
GitLab CI/CD	Project Settings, CI/CD, Variables	Publish from GitLab CI/CD
CircleCI	Org, Contexts (or Project Settings, Environment Variables)	Publish from CircleCI
Jenkins	Manage Jenkins, Credentials, a Secret text credential	Publish from Jenkins
Bitbucket Pipelines	Repository settings, Pipelines, Repository variables, Secured	Publish from Bitbucket Pipelines

Each guide has a tab for Maven, Gradle, npm, Python and Docker. A tab shows what the pipeline needs to read the token: copy it, replace the placeholders (your-org, your-repo, you@example.com) with your own values, and adapt it to your build.

The rule every guide follows

1. Create the token for the pipeline. Use a token that reaches only the repositories the pipeline needs, Read only if it only pulls and Read + write if it publishes. Give it an expiry, and replace it before that date. Rotating a token gives you a new value but keeps the same expiry, so it does not extend the token’s life: create a new token with a new expiry, put it in your platform’s secret, then revoke the old one.
2. Create it as an account that outlives any one person. A token you create under Repository Tokens belongs to your account. Deleting a user from your organization deletes that user’s tokens, and any pipeline using one stops authenticating. A user you make for builds (see Create Your First User), signed in to the admin portal when it mints the token, keeps your builds working when a teammate leaves. The owner can instead create a service key, which belongs to your organization rather than to a user.
3. Store the token as a secret named CLOUDREPO_TOKEN in your platform.
4. Name the variable in a committed file; never the token. Maven reads ${env.CLOUDREPO_TOKEN} in settings.xml, npm reads ${CLOUDREPO_TOKEN} in .npmrc, Gradle reads providers.environmentVariable("CLOUDREPO_TOKEN"), twine reads TWINE_PASSWORD, and docker login reads the token from standard input. The guides show each one.
5. Keep the token off the command line. A process listing shows a command’s arguments to other users of the machine. Every block in the guides passes the token through the environment, a file or standard input.

The username every client sends, where it sends one, is the email address of the account that created the token. npm sends the token alone. See Repository Tokens for each client’s credential and for what a 401, 403 or 404 means.

Another CI system

The blocks in these guides use only environment variables, files and standard input, so they carry to any CI that can set an environment variable from a secret store. Put the token in that store as CLOUDREPO_TOKEN, and use the client’s block from the guide of the platform closest to yours. If a platform’s guide would save you time, email support@cloudrepo.io.