Vetrix Docs

Pipelines

A pipeline is one run of a repository's CI/CD jobs, grouped into stages and triggered by a commit, a schedule, or a manual start. This page covers the three places you read pipelines — a repository's pipeline list, a single pipeline's jobs and logs, and the CI/CD overview that gathers recent runs from every repository you own — and the repository CICD settings screen where you set CI/CD policy and manage the hosts that run the jobs.

Where to find it

  • Repository pipelines: gitvetrix.com/{owner}/{repo}/pipelines
  • A single pipeline: gitvetrix.com/{owner}/{repo}/pipelines/{id}
  • CI/CD overview across your repositories: gitvetrix.com/pipelines
  • Repository CI/CD settings: gitvetrix.com/{owner}/{repo}/settings/cicd
  • Navigation: Open a repository and select Pipelines in the left sidebar. The list opens with the most recent runs first, and your filters are kept in the page address so you can bookmark or share a filtered view.

Read the pipeline list

The repository pipeline list is a table with one row per run and these columns:

  • Status — an icon and a label for the run's state: Success, Failed, Running, Cancelled, Skipped, Waiting, or Pending.
  • Ref — the branch or tag the run is for, with the person who started it shown below it.
  • Commit — the short commit identifier.
  • Trigger — how the run started: Push, Manual, or Schedule.
  • Duration — how long the run took, or a dash while it is still running.
  • Jobs — a compact tally of the run's jobs, counting those that succeeded, failed, and are still running.
  • Started — how long ago the run began.
  • Actions — the controls for the row (see Start, cancel, retry, or delete a run from the list).

While any runs are in progress, the list refreshes on its own so the status and duration stay current.

Filter the list

Use the toolbar above the table to narrow the runs:

  1. State — a button group with All, Running, Success, Failed, and Cancelled. Select one to show only runs in that state.
  2. Trigger — a dropdown with All triggers, Push, Manual, and Schedule.
  3. Ref — type a branch or tag name into the Filter by branch / tag… box and press Enter to limit the list to that ref.

Each choice is added to the page address, so a filtered list can be bookmarked or shared. When more than 25 runs match, a pager appears below the table for moving between pages.

Start, cancel, retry, or delete a run from the list

The controls in the Actions column and the Run pipeline button appear only when you have permission to run CI/CD in the repository. If you have read-only access, you still see the list and can open any run.

  • Run pipeline — at the top-right of the toolbar, starts a new run.
  • Cancel — on a Running or Pending run, stops it.
  • Retry — on a Failed or Cancelled run, starts it again and opens the new run.
  • View — opens the run's detail page.
  • Delete — removes the run. A confirmation dialog names the run and warns that all of its jobs, logs, and artifacts are removed and that the action cannot be undone. Select Delete pipeline to confirm.

Open a pipeline

Select a run's Ref or its View action to open the detail page. The header shows:

  • A status badge for the run's state. When the run passed but tolerated a job that was allowed to fail, the badge instead reads success with warning.
  • The short run identifier, the ref, and the short commit.
  • Triggered by and the name of the person who started it, how the run started, when it Started, and its Duration.

The header also carries the run's actions:

  • Cancel — shown on a Running or Pending run. It opens a confirmation dialog that names the run before stopping it.
  • Retry — shown on a Failed or Cancelled run. It starts the run again straight away.
  • Delete — shown when you have permission to run CI/CD. It opens a confirmation dialog before removing the run and all of its jobs, logs, and artifacts.

While any job is still running, waiting, or pending, the page refreshes on its own.

Read the jobs

Below the header, the run's jobs are listed one per line, grouped by stage. Each line reads as a sentence in the form stage: job — status, where the status is Succeeded, Failed, Running, Pending, Cancelled, Skipped, or Waiting. Extra cues appear on the line when they apply:

  • A job that was allowed to fail and did reads Failed (allowed) and carries an Allowed to fail badge, so a tolerated failure never looks like a blocking error.
  • A stage that cannot start until an earlier stage finishes reads with (gated by an earlier stage) and carries a Gated badge.
  • A job that a resource limit stopped carries a badge naming the reason: Timed out, Out of memory, or Disk quota exceeded.
  • When a job's run time is known, it appears at the end of the line.

Select a job line to open its log below the list. Select the same line again to close the log.

Read a job's log

The log panel opens under the job list for the job you selected. A toolbar across the top of the panel shows the job's name, its run time, its exit code when the job has finished, any resource-limit reason, the resolved resource limits that applied, and the image the job ran in when those are recorded. The toolbar also holds the log controls:

  • Pause auto-scroll — stops the view from jumping to the newest line as output arrives; the button face then reads Paused, and its tooltip reads Resume auto-scroll. New lines keep arriving in the background.
  • The follow-tail control keeps the newest line in view; its tooltip reads Enable follow tail or Disable follow tail.
  • Copy log to clipboard — copies the full log. A Copied! note confirms.
  • Download — saves the full log as a file.

While a live job produces no output yet, the panel reads Waiting for log output…. If a log cannot be loaded, the panel shows a short failure message in its place rather than blank output.

Very long logs are capped. When output runs past the cap, a banner reads, for example, Showing last 2,000 of 5,000 lines (3,000 hidden) with a Show all lines control; while showing everything, a Cap at 2,000 lines control returns to the capped view.

When a job produced downloadable files, an Artifacts list appears at the foot of the panel. Each entry is a download link whose name includes the file name and its size, for example Download bundle.tar.gz (4.2 MB).

See CI/CD across all your repositories

The CI/CD overview at gitvetrix.com/pipelines gathers the most recent runs from every repository you own into one table titled CI/CD Pipelines. Its columns are Status, Repository, Ref, Commit, Trigger, Started, and Actions. Select a repository name to jump to that repository's pipeline list, or use a row's View action to open the run's detail page. As with the per-repository list, the overview refreshes on its own while any run is in progress.

When you have no runs yet, the overview reads No pipelines yet and explains that pushing a commit to a repository that defines a pipeline starts your first run.

Configure repository CI/CD settings

Open a repository's Settings, then select the CICD tab to reach the CICD settings screen. It sets the CI/CD policy for the repository and lists the hosts that run its jobs. A note at the top explains that the effective policy is the merge of the app, organization, user, and repository layers, and that a lower layer can only narrow what a higher layer already allows.

Set the CI/CD policy

The policy form sits on the left of the screen:

  • Image allowlist — the container images jobs may run in. Add an entry in the new-entry box (for example docker.io/library/alpine:3.20) and remove any entry you no longer want.
  • Resource limits — the caps applied to each job: CPU (cores), Memory (bytes), and Pids limit.
  • Cache TTL — how long a job cache is kept, in Cache TTL (seconds).

Select Save defaults to apply your changes. A confirmation note reports when the policy is saved.

Preview the effective policy

Beside the form, the Effective policy panel shows the policy that actually applies to the repository once the app, organization, user, and repository layers are merged. It updates as you save, so you can see how your repository-level changes combine with the caps set above you.

Manage attached hosts

The Attached hosts panel lists the hosts that can run this repository's jobs, one per row, with the host's Name, Executor, Capacity, Status, In-flight job count, and an action. A host's status reads Active, Draining, or Decommissioned.

  • To remove a host attached directly to this repository, select Detach. Detaching drains the host gracefully — in-flight jobs are allowed to finish before the host is removed.
  • A host that a repository inherits from a wider scope shows where it comes from — for example Inherited from organization, Inherited from user, or Shared pool host — and cannot be detached here; it is detached at the scope that owns it.

When nothing is attached, the panel reads No hosts are attached to this repo yet.

  • Configuring a pipeline — add the pipeline configuration file, understand what triggers a run, and manage per-branch pipeline variables.
  • Creating a repository — create a repository whose commits can trigger pipelines.
  • Repository home — the repository landing page and its branch, clone, and activity controls.