CLI

Streamline CI/CD with SleakOps CLI

SleakOps CLI is a Python package designed to simplify your CI/CD workflows. With just two straightforward subcommands, you can effortlessly create builds and deploy your applications, ensuring a smooth and efficient development process. To get started, simply install SleakOps using pip:

pip install sleakops

1. Authentication

To authenticate with the SleakOps CLI, you need an API_KEY. You can obtain this key from the console by clicking on Generate API-Key. Each company is allowed to have only one active API_KEY at a time. If you request a new API_KEY, the old one will be automatically revoked. The page shows the company keys and who generated them.

Once you have your API_KEY, you can use it as an argument when running SleakOps commands or set it as an environment variable named SLEAKOPS_KEY.

Setting up SLEAKOPS_KEY in CI/CD Pipelines

For CI/CD pipelines, it's recommended to set SLEAKOPS_KEY as a secret environment variable in your Git provider:

• GitHub: Add it as a repository secret in Settings → Secrets and variables → Actions
• GitLab: Add it as a CI/CD variable in Settings → CI/CD → Variables
• Bitbucket: Add it as a repository variable in Repository settings → Pipelines → Repository variables

This ensures secure access to SleakOps services without exposing your API key in your pipeline configuration files.

2. Create a Build

To create a build for your application, use the following command:

sleakops build [options]

This command initiates the build process, and SleakOps takes care of compiling your code, running tests, and packaging the application for deployment. You can specify additional options to tailor the build process to your specific needs.

There are two required arguments project and branch, which are used to know what to build. Besides, you might add a commit to build a previous commit, a tag for the image, and the provider if you need to specify it.

As previously mentioned the key might be an input here or a environment variable.

Also, you might mark if you want the process to wait the build to be finished or not.

You can set a timeout (in minutes) for a build. This is the build's maximum lifetime on the backend: if the build runs longer, SleakOps stops it and marks it as failed, so a stuck build can't hang forever. It defaults to 180 minutes, and every build is bounded even if you don't pass it. When you also use wait, --timeout caps how long the CLI watches the build too. The CLI's default can be set through the BUILD_TIMEOUT_MINUTES environment variable.

Option	Description
--wait	Wait for the build to finish before returning.
--timeout	Maximum build lifetime in minutes; also caps how long the CLI watches with --wait. Default 180. 0 keeps the platform default and lets --wait watch indefinitely.

tip

--timeout works on two levels: the backend stops the build once it exceeds the limit (this happens for every build, even without --wait), and — when you pass --wait — the CLI also stops watching after the same time and exits with code 1, so a stuck build fails your CI pipeline instead of hanging.

3. Make a Deploy

Once your build is ready, you can effortlessly deploy your application using the following command:

sleakops deploy [options]

SleakOps seamlessly handles the deployment process, ensuring that your application is up and running in no time. You can specify deployment options to fine-tune the process according to your requirements.

Here project and environment are the required arguments. User might add a build or tag image to specify an image. Here the wait and key options are present to, the usage is the same as in the build command.

Injecting values on deploy

You can inject Helm values into a single deployment, on top of everything configured in the platform (see Values for the override levels):

sleakops deploy -p myapp -e prod -f values.prod.yaml
sleakops deploy -p myapp -e prod --set api_web.replicas=3
cat values.yaml | sleakops deploy -p myapp -e prod -f -

Option	Description
-f, --values	YAML file with values for this deploy (repeatable; - reads stdin; later files win).
--set	Set a single value, key.path=value (repeatable; wins over -f). YAML coercion applies: 5 → int, true → bool.
--set-string	Like --set but the value is always kept as a string (no coercion).

Ephemeral by design

Deploy-time values apply to that deployment only — they win over every value configured in the platform, and the next deploy without -f/--set/--set-string reverts to the platform values. They are the right tool for one-off tweaks, not for durable configuration: make durable changes at the project or workload level instead.

Two caveats:

• For secrets prefer -f (or stdin): --set and --set-string arguments stay in your shell history and CI logs.
• Two different list semantics: between your own inputs (-f files and --set flags) a list replaces the previous one, exactly like Helm. But when your deploy values merge against the platform levels, lists are combined instead of replaced — an entry you pass is added to the generated ones, it doesn't drop them.

CI/CD Examples

With SleakOps CLI, you can integrate your CI/CD pipelines, automate the build and deployment process, and focus on delivering exceptional applications without the hassle of manual intervention. Enjoy a seamless development experience with SleakOps, and make your custom CI/CD workflows.

GitHub

name: Deploy

on:
  push:
      branches:
            - main
jobs:
  build:
      runs-on: ubuntu-latest
      steps:
            - name: Checkout repository
        uses: actions/checkout@v2
              - name: Install SleakOps CLI
        run: pip install sleakops
              - name: Run SleakOps build
        env:
          SLEAKOPS_KEY: ${{ secrets.SLEAKOPS_KEY }}
        run: sleakops build -p core -b main -w
  deploy:
      needs: [build]
      runs-on: ubuntu-latest
      steps:
            - name: Checkout repository
        uses: actions/checkout@v2
              - name: Install SleakOps CLI
        run: pip install sleakops
              - name: Run SleakOps deploy
        env:
          SLEAKOPS_KEY: ${{ secrets.SLEAKOPS_KEY }}
        run: sleakops deploy -p core -e main -w

GitLab

image: python:3.9

stages:
    - build
    - deploy

build:
  stage: build
  script:
        - apt-get update -qy
        - apt-get install -y python3-pip
        - pip3 install sleakops
        - sleakops build -p core -b main -w
  rules:
        - if: '$CI_COMMIT_BRANCH == main'

deploy:
  stage: deploy
  needs:
        - build
  script:
        - apt-get update -qy
        - apt-get install -y python3-pip
        - pip3 install sleakops
        - sleakops deploy -p core -e prod -w
  rules:
        - if: '$CI_COMMIT_BRANCH == main'

BitBucket

image: python:3.9

pipelines:
  branches:
    main:
            - step:
          name: Deploy
          script:
                        - apt-get update -qy
                        - apt-get install -y python3-pip
                        - pip3 install sleakops
                        - sleakops build -p core -b main -w
                        - sleakops deploy -p core -e main -w

FAQs

Does SleakOps use webhooks for CI/CD?

No. SleakOps does not use webhooks to trigger CI/CD pipelines. Instead, the CI/CD process is executed through SleakOps CLI commands running in your pipeline runners: GitHub Actions, GitLab Runners, or Bitbucket Pipelines.

What should I do if the CLI returns "Multiple projects found with the same name and branch"?

This message appears when you have multiple projects with the same name across different environments. To resolve this, specify the environment using the -e or --environment parameter in your build or deploy commands. If you need more information about options for this command see sleakops sub-command --help

The environment name must match exactly with the environment configured in SleakOps. You can find the correct environment value in the pipeline examples located at Project → Settings → Git Pipelines.