CI/CD Pipelines

GitBlixt runs continuous integration pipelines for your repositories. It understands both GitLab CI (.gitlab-ci.yml) and GitHub Actions (.github/workflows/*.yml) configuration, so most repositories work without changing their existing config. Jobs execute in isolated Docker containers, and you watch logs stream live in the web UI.

How pipelines trigger

A pipeline is created automatically whenever you push to a repository (over SSH or HTTP). You can also start one manually from the Pipelines tab: pick a branch and click Run pipeline. Pipelines are scoped to the branch (ref) and commit (SHA) they ran against.

The pipeline list lives at /<namespace>/<repo>/-/pipelines. Each pipeline links to a detail page at /-/pipelines/<pipeline_id>, and each job to /-/pipelines/<pipeline_id>/jobs/<job_id>.

Configuration

When a pipeline runs, GitBlixt looks for config in this order — the first match wins:

1. GitHub Actions workflows in .github/workflows/ (files ending in .yml or .yaml)
2. GitLab CI in .gitlab-ci.yml at the repository root

If neither exists, the pipeline succeeds immediately with no jobs. Only GitHub Actions workflows whose on: trigger matches a push to the pipeline's branch are run.

GitLab CI example

Jobs are grouped into stages, which run in order. If you don't declare stages:, the defaults are build, test, deploy. A job's script runs inside the container named by its image.

stages:
  - test

unit:
  stage: test
  image: elixir:1.17
  script:
    - mix deps.get
    - mix test

GitHub Actions example

GitHub Actions jobs are translated into the same job/stage model. Stages are derived from the needs: dependency graph, and common setup actions are mapped to equivalent commands. Expressions like ${{ ... }} are evaluated where supported.

name: CI
on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "Building on ${{ github.ref }}"
      - run: ./run-tests.sh

Stages and jobs

Each stage's jobs are dispatched when the previous stage completes; jobs within the first stage start as soon as the pipeline begins. Every job is an entry in the pipeline detail view showing its stage, status, duration, and exit code.

Statuses

Pipelines and jobs share the same set of statuses:

Job logs

Open any job to see its log. Output streams live over the websocket while the job runs and is persisted so you can review it afterward. Use the Copy log button to grab the full output.

Manual actions

From a pipeline or job page you can:

• Cancel — stop a pending or running pipeline; any running job containers are killed
• Re-run — re-trigger a finished (success/failed/canceled) pipeline against the same branch and commit
• Clear cache & re-run — wipe the repository's CI build cache, then re-trigger

CI/CD variables

Variables are defined per repository under Settings. They are injected as environment variables into CI job containers. Each variable has:

CI/CD variables are for CI pipeline jobs only. They are not passed to deployed applications — deployed apps get their own environment variables, configured separately on each app environment.

Artifacts

Jobs can produce artifacts — files saved after a job runs. Each artifact records a file_type (defaults to archive), file_name, file_path, size, and an optional expire_at timestamp after which it can be cleaned up.

External runners (GitLab Runner API)

In addition to the built-in Docker executor, GitBlixt exposes a GitLab Runner–compatible API so external runners can pull and execute jobs. Authenticate with a personal access token (PRIVATE-TOKEN or Authorization: Bearer header). The runner is handed the next pending job belonging to a repository owned by the authenticated user.

When a runner reports a job as success, failed, or canceled, GitBlixt recalculates the overall pipeline status automatically.