# Cadence.CI

> DevOps, DataOps & MLOps continuous integration platform that removes integration barriers, enables full collaboration between domains, and optimizes CI infrastructure costs.

Cadence.CI is a continuous integration platform designed for DevOps, DataOps and MLOps teams. It reduces CI/CD costs, enables deep debugging, supports AI pipelines, and integrates with existing workflows. The platform is built on top of Mélodium, a distributed pipeline language. Documentation is available under /en/docs. The product is available at https://cadence.ci.

This optional agentmarkup context file expands the published llms.txt manifest with inline same-site markdown content when those mirrors are available.

## Product

- [Home](https://cadence.ci/en.md): Overview of Cadence.CI features and value proposition: remove integration barriers, cut CI costs, enable full DevOps & MLOps.
- [Use Cases](https://cadence.ci/en/use-cases.md): Concrete use cases: AI pipelines connecting agents, deep debugging with stream inspection, vibe coding, multi-domain collaboration.
- [Pricing](https://cadence.ci/en/pricing.md): Plans and pricing: Access (free), Pro, and Enterprise tiers with compute credits and cluster options.
- [For ML Teams](https://cadence.ci/en/for-ml.md): Cadence.CI capabilities specifically relevant to machine learning and data science workflows.

### Home

> Overview of Cadence.CI features and value proposition: remove integration barriers, cut CI costs, enable full DevOps & MLOps.

Source: https://cadence.ci/en
Preferred fetch: https://cadence.ci/en.md

Cadence.CI gives you observable, robust, and safe integration pipelines. Full control from execution to delivery.
Checked before anything runs, on infrastructure you already own.

 Start for free See how it works

Run Integrations Where It Should

Use the provider you want. Stay close to your infrastructure. Change locations seamlessly.

Orchestrate With Fine and Clear Rules

Fully customizable orchestration mechanisms. Unlimited concurrency.

Get Detailed Insights

Access to granular data and streams. Analyze and reproduce. Insure compliance.

Avoid Slowing Projects and Hidden Costs

Safety by design. Improve developers and product feedback. Improve deliverability.

### Use Cases

> Concrete use cases: AI pipelines connecting agents, deep debugging with stream inspection, vibe coding, multi-domain collaboration.

Source: https://cadence.ci/en/use-cases
Preferred fetch: https://cadence.ci/en/use-cases.md

### Checked Before It Runs

No more debugging by push

The whole pipeline, types, connections, every parameter, is validated before a single runner is
provisioned. A malformed pipeline never becomes an invoice, and a mismatched step never costs you the
ten minutes it takes to find out on a runner.

### AI Pipelines

Route, bound, and prove where the data goes

Route each request to the model that actually needs to answer it, and keep the boundary between what
runs locally and what reaches a remote model visible in the pipeline itself, not in a policy
document.

### Sovereign Projects

Technological and legal independence

Cadence.CI runs on Libre and Open-Source technology, and our infrastructure partners are incorporated
and located in the EU, with managed clusters in Paris, Amsterdam, and Warsaw. If we disappeared
tomorrow, you would lose a dashboard, not your ability to build software: the engine has no runtime
dependency on us.

#### Platform Interoperability

Run locally, on any cloud, where you want

Integrates on any cloud provider and location, distribute across different platforms without limitations. Cadence.CI does not rely on specific provider or system.

#### Air Gap

Run physically isolated

Allows pipelines to run totally isolated from outer world. No data exchange nor external runtime dependency. Run it on your local infrastructure, in your dedicated private cloud, or on your isolated network.

#### Deep Debugging

Do not only rely on logs

Get full insights of what happens and where streams comes from and goes, analyze true debug events.

#### Specific Systems and Infrastructure

Manage integration on industry-specific systems

Linux, macOS, and Windows, with released binaries for x86-64, ARM64, and i686. s390x and RISC-V build and check in our own CI today; ask if your infrastructure needs either as a released target.

#### Growing Teams

Involves more people without breaking things

Allowing many people to collaborate on projects while making sure things continue to work smoothly is a challenge. Cadence.CI insure scaling teams and projects full continuity, preventing unexpected breaks.

#### Vibe Code

Express what you want

Build in accordance of your vibe projects. Make integration processes that you can see. Understand what it does. Explain it to others.

## Want to know more?

Every project is unique, and Cadence.CI will not have the same impact on each of them.
If you need some guidance or informations, feel free to reach us.

### Pricing

> Plans and pricing: Access (free), Pro, and Enterprise tiers with compute credits and cluster options.

Source: https://cadence.ci/en/pricing
Preferred fetch: https://cadence.ci/en/pricing.md

## Pricing

Accelerate Integration & Delivery

No minutes cap, no concurrency limit blocking your team, no runners sitting idle. Cadence.CI runs on infrastructure you already pay for, exploited fully instead of rationed.

### Access

Free

Start in minutes. Run on your existing runners with no infrastructure change.

- Connect your cloud accounts and spawn VMs directly. No minutes cap, pay as you go at your provider's rates.
- Logs & debug events for every run
- Integrates natively within your GitHub and GitLab repositories
- Runs on your existing GitHub and GitLab runners, no infrastructure change needed
- No infrastructure to migrate: keep your current runners and evaluate risk-free

 Register

### Basic

 Early Adopter

 $35 per user / month

excl. tax, billed annually

Bring your own clusters and cut infrastructure costs up to ÷10 vs GitHub Actions.

- Everything in Access
- Smart scheduling to eliminate idle compute waste
- Admin & User roles for team access control
- 120-day run history for debugging and compliance
- Connect your cloud projects to run closer and cost less
- Cut idle infra spend with pay-as-you-go spawning

 Get Started

 Most Popular

### Pro

 Early Adopter

 $62 per user / month

excl. tax, billed annually

Full governance for growing teams. Fine-grained cost controls, compliance-ready audit history, and on-premise hosting for sovereignty.

- Everything in Basic
- Fine-grained machine policies to optimize costs at scale
- Cut debug time with fine-grained cost and audit visibility
- Custom user roles with organization-wide access control
- Permission groups for safe team scaling
- Fully customizable webhooks and event integrations
- 1-year audit trail for compliance and post-incident analysis

 Get Started

### Enterprise

 On Demand

On Quote

excl. tax, billed annually

Maximum sovereignty for regulated environments. On-premise, air-gap, unlimited scale, and dedicated SLA.

- Everything in Pro
- Air-gap and on-premise deployment for full data sovereignty
- Fully managed clusters handled by our teams
- Unlimited users with custom role structures
- Custom SLA and dedicated support

Features

Access

Basic

Pro

Enterprise

Github & GitLab Integration

 Visual Pipeline Editor

Logs and Debug Events Inspection

Concurrent Jobs

10,000

Unlimited

Unlimited

Unlimited

Active Users

10

Unlimited

Unlimited

Unlimited

Control Pane

Shared

Shared

Dedicated

On-Premise

Self-Provided Runners Integration

Cloud Provider Integrations (Scaleway, AWS)

Kubernetes Clusters Connections

User Roles

Admin & User

Admin & User

Custom Roles

Custom Roles

Per-step Machine Targeting

Permission Groups

Custom Webhooks

Dedicated and On-Premise Hosting

Fail-Fast Validation & In-Memory Secret Isolation

Data Retention

7 Days

120 Days

1 Year

Custom

Cadence.CI is more than features: it means time and costs reduction

Calculate your Cadence.CI benefits

Know how much integration currently costs you

###

 Developers in your team

5

 Average developer cost/month

 Typical CI run duration

30 minutes

###

 Runs per developer per day

4

 Run failure rate

10%

 Average debug time per failure

25 minutes

 CI maintenance hours per week

4h

###

## Compare

 Infrastructure Waiting Context switching Debugging Maintenance

## Benefits

8.3

Workdays recovered per month

+$7,114

Earned amount per month

0.7

Equivalent headcount per year

### Monthly

### Annually

 Time earned per month per user 13 hours, 12 minutes

 Time earned per year per user 6 days, 14 hours, 24 minutes

 Workdays earned per month 8.3

 Workdays earned per year 99.6

 Earned amount per month +$7,114

 Earned amount per year +$85,363

## Contact Us

## How It Works

- [General Architecture](https://cadence.ci/en/docs/how-it-works/general.md): Core principles: observability, collaboration, security. Distributed pipelines via Mélodium with data streams, event reactions, and process management.
- [Programming Language](https://cadence.ci/en/docs/how-it-works/programming-language.md): The Mélodium language used to define CI/CD pipelines: syntax, concepts, and how it differs from traditional CI YAML.
- [Cloud Integration](https://cadence.ci/en/docs/how-it-works/clouds.md): How Cadence.CI integrates with cloud providers so runners execute inside your own cloud project.
- [Kubernetes Integration](https://cadence.ci/en/docs/how-it-works/kubernetes.md): Running Mélodium runners as pods inside your own Kubernetes cluster.

### General Architecture

> Core principles: observability, collaboration, security. Distributed pipelines via Mélodium with data streams, event reactions, and process management.

Source: https://cadence.ci/en/docs/how-it-works/general
Preferred fetch: https://cadence.ci/en/docs/how-it-works/general.md

**Cadence.CI** is a DevOps platform built around three principles: **observability**, **collaboration**, and **security**. This page covers the architecture and concepts that underpin the platform.

## Core Technology

**Cadence.CI** relies on [Mélodium](https://melodium.tech/) to implement **distributed pipelines** by handling **data streams**, **event reactions**, and **process management** in a way that is **scalable**, **reproducible**, and **fault-tolerant**.

### Data Streams as First-Class Citizens

Mélodium treats data streams as the fundamental unit of computation. Streams can be distributed, transformed, and processed across multiple nodes, enabling real-time and scalable data handling. Streams are **typed and generic**, allowing for safe and reusable pipeline code across different data types and environments.

### Event-Driven and Reactive Programming

Treatments react to incoming data or events rather than following a predefined execution order. This is particularly useful for integration pipelines, real-time analytics, and distributed task processing where execution depends on data availability.

### Cross-Platform Support

Mélodium's distribution system runs on diverse platforms, from constrained embedded systems to large-scale cloud infrastructure. Abstraction layers handle platform-specific details, letting pipeline authors focus on logic rather than deployment.

## Infrastructure and Distribution

Cadence.CI dynamically spawns runners across **diverse infrastructures** and **cloud providers** in a truly infrastructure-agnostic way.

### Infrastructure Agnosticism

Cadence.CI keeps users free to choose and mix cloud and on-premises environments. Runners can be deployed on:

- **Public clouds** ([Scaleway](https://www.scaleway.com/) and AWS today, more providers planned)
- **On-premises infrastructure** (any Kubernetes cluster, self-managed or Melodium-operated)
- **Hybrid environments** (mixing cloud and on-prem)

### Dynamic Runner Spawning

Runners are provisioned on demand and terminated when the job completes:

- **On-demand provisioning**: runners spawn only when needed, eliminating idle resource costs.
- **Auto-scaling**: the system scales up or down based on pipeline demand.
- **Ephemeral runners**: each runner is created for a specific job and destroyed afterward, improving both efficiency and security posture.

### Unified Abstraction Layer

Mélodium shares pipeline specifications with Cadence.CI regardless of the underlying infrastructure. Cadence.CI translates Mélodium's requests into provider-specific actions, launching an EC2 instance on AWS, an instance on Scaleway, or a pod on Kubernetes, while presenting a consistent interface to the pipeline author.

```mermaid
flowchart TD
  cadence((Cadence.CI))

  subgraph Infra A
    subgraph Runner_1
        mel1[Mélodium]
        containerAa1@{shape: procs, label: "Container"}
        containerAa2@{shape: procs, label: "Container"}
        mel1 --- containerAa1
        mel1 --- containerAa2
    end

    subgraph Runner_2
        mel2[Mélodium]
        containerAb1@{shape: procs, label: "Container"}
        mel2 --- containerAb1
    end
    
  end

  subgraph Infra B
    subgraph Runner_3
        mel3[Mélodium]
        containerBa1@{shape: procs, label: "Container"}
        containerBa2@{shape: procs, label: "Container"}
        mel3 --- containerBa1
        mel3 --- containerBa2
    end

    subgraph Runner_4
        mel4[Mélodium]
    end

    subgraph Runner_5
        mel5[Mélodium]
    end
    
  end

  mel0["Mélodium\n(Initial process)"]

  mel0 -.->|Request Spawns| cadence

  cadence -.->|Spawns| Runner_1
  cadence -.->|Spawns| Runner_2
  cadence -.->|Spawns| Runner_3
  cadence -.->|Spawns| Runner_4
  cadence -.->|Spawns| Runner_5

  mel0 ---|Distribute| mel1
  mel0 ---|Distribute| mel2
  mel0 ---|Distribute| mel3
  mel0 ---|Distribute| mel4
  mel0 ---|Distribute| mel5
```

## Monitoring and Debugging

Cadence.CI provides **monitoring and debugging** for Mélodium executions, aggregating logs and execution data from runners regardless of whether they run on cloud, on-prem, or hybrid infrastructure.

### Log and Debug Aggregation

Runners upload logs and debug data to Cadence.CI in chunks as execution progresses, appearing in the dashboard shortly after each upload, and you can browse them per run, including a full program dump of what was executed.

### Run-Level Execution Data

For each run, Cadence.CI records:

- **Execution state**: request, start, and end times, current status (scheduling, running, finished, unschedulable), and the success/failure result.
- **Entrypoint and parameters**: the exact treatment entrypoint and input parameters the run was launched with.
- **Resource requests**: CPU, memory, and storage requested for the run's engine, containers, and service containers.

Treatment-level debugging, time-travel replay, alerting, and metrics export are on the [roadmap](/en/docs/roadmap#monitoring-and-debugging).

## Organization and Security

### Roles and Invitations

Users belong to an organization and hold a role (Admin, Operator, or Lambda) that governs what they can do, such as managing cluster tokens or browsing cluster details. Admins can invite new users to the organization by email, and roles and access apply at the organization level.

Team-level grouping and per-project/per-runner permission scoping are on the [roadmap](/en/docs/roadmap#organization-and-security).

### Bring Your Own Infrastructure

Cadence.CI follows a "Bring Your Own Infrastructure" (BYOI) model: pipeline orchestration runs on Cadence.CI, while compute runs on infrastructure you control, your own cloud provider account or your own Kubernetes cluster.

```mermaid
flowchart TD
  cadence["Cadence.CI\n(orchestration + observability)"]

  subgraph "Your Infrastructure"
    vpc["Private Network / VPC / On-Prem"]
    runner1["Runner"]
    runner2["Runner"]
    vpc --- runner1
    vpc --- runner2
  end

  cadence -->|spawn + coordinate| vpc
  runner1 -.->|logs + telemetry| cadence
  runner2 -.->|logs + telemetry| cadence
```

This model provides:

- **Data sovereignty**: sensitive data stays within your private infrastructure, and runners can be placed in specific regions to meet data residency requirements (GDPR, CCPA, etc.).
- **Network isolation**: runners can be deployed in isolated VPCs, on-prem data centers, or air-gapped environments.
- **Compliance alignment**: because you control the infrastructure, you can meet strict requirements (HIPAA, PCI DSS, SOC 2, ISO 27001) by running on already-certified environments.
- **Ephemeral runners**: runners are short-lived, eliminating idle attack surface.

Organizations that prefer to run on infrastructure operated by Melodium can use shared or dedicated clusters instead, see [Kubernetes integration](/en/docs/how-it-works/kubernetes#self-managed-vs-melodium-operated-clusters) for the distinction.

Per-team runner/secret scoping and IAM integration with external identity providers are on the [roadmap](/en/docs/roadmap#organization-and-security).

### Core-Level Security

Cadence.CI leverages Mélodium's runtime properties for security guarantees that are built into the execution layer itself:

- **Fail-fast validation**: the entire program is validated at startup. Invalid configurations and unsafe setups halt immediately, before any runner is spawned or any compute is provisioned.
- **In-memory secret handling**: sensitive values are identified in memory, kept isolated to the treatment using them, and securely erased after use.

### Programming Language

> The Mélodium language used to define CI/CD pipelines: syntax, concepts, and how it differs from traditional CI YAML.

Source: https://cadence.ci/en/docs/how-it-works/programming-language
Preferred fetch: https://cadence.ci/en/docs/how-it-works/programming-language.md

Integration pipelines are fundamentally programs, they orchestrate tasks, route data, react to events, and coordinate work across multiple machines. Yet most pipeline tools rely on approaches that were never designed for this purpose.

## Why Existing Approaches Fall Short

### YAML-Based Configuration

Tools like GitHub Actions, GitLab CI, and CircleCI represent pipelines as YAML files describing sequences of shell commands. This works for simple cases but quickly hits structural limits:

- **No native data passing**: data between jobs must be serialized to disk, uploaded as artifacts, then downloaded and deserialized in the next job. There is no concept of a stream.
- **Coarse parallelism**: jobs can run in parallel, but coordination within a job is sequential. Fine-grained concurrency requires workarounds.
- **Limited expressivity**: conditionals are awkward, loops are limited or absent, and anything beyond a linear sequence requires external scripting.
- **Flat observability**: a failed run produces flat logs. There is no structured trace of what treatment received what input, diagnosing failures means grepping through output rather than inspecting state.

### Imperative Scripting

Groovy (Jenkinsfile), Python, and similar scripting languages offer more flexibility, but introduce their own problems when used for pipeline orchestration:

- **Sequential mental model**: scripts execute line by line. Expressing concurrent execution, fan-out, or reactive behavior requires explicit thread management or async constructs not designed for this use case.
- **No native distribution**: distributing work across machines requires writing coordination code, SSH calls, job queues, or custom orchestration. The pipeline author manages distribution, not the language.
- **Manual stream handling**: passing a stream of bytes or events between machines means writing buffering, chunking, and error recovery code by hand.
- **Opaque topology**: a script has no intrinsic structure that tooling can inspect. Debugging means reading execution logs, not understanding the shape of the program.

## Why Mélodium Fits

Mélodium was designed specifically for programs that CI/CD pipelines actually are: **distributed**, **stream-oriented**, **reactive**, and **inspectable**.

```mermaid
graph TD
  subgraph yaml["YAML / Scripted Pipelines"]
    y1[Step A] -->|artifact upload| y2[Step B]
    y2 -->|artifact upload| y3[Step C]
    y3 -->|artifact upload| y4[Step D]
  end

  subgraph mel["Mélodium Pipelines"]
    m1[Treatment A] -->|typed stream| m2[Treatment B]
    m1 -->|typed stream| m3[Treatment C]
    m2 -->|typed stream| m4[Treatment D]
    m3 -->|typed stream| m4
  end
```

*YAML pipelines pass data through sequential artifact uploads. Mélodium treatments connect via typed streams and execute concurrently as soon as their inputs are available.*

### Streams as First-Class Citizens

Data flows between treatments as typed streams, no serialization round-trips between stages. Files, bytes, and structured values move directly from one treatment to the next, even across machine boundaries. The type system ensures that a `Stream<byte>` cannot be accidentally wired to an input expecting a `Block<string>`, catching connection errors before any execution begins.

### Native Distribution

A Mélodium program declares *what runs where*. The runtime handles spawning processes on remote machines, establishing connections between them, and coordinating execution. The pipeline author writes logic; Mélodium handles the distribution. There is no coordination code, no SSH scaffolding, and no job queue to manage.

```mermaid
flowchart LR
  subgraph "Local / Initial Process"
    entry[Entrypoint Treatment]
  end

  subgraph "Runner A (Cloud)"
    t1[Treatment B]
    t2[Treatment C]
  end

  subgraph "Runner B (On-Prem)"
    t3[Treatment D]
  end

  entry -->|typed stream| t1
  entry -->|typed stream| t3
  t1 -->|typed stream| t2
  t2 -->|typed stream| t3
```

*The same Mélodium program can distribute treatments across machines on different infrastructures. The connection topology is declared in the program, the runtime handles the rest.*

### Reactive Execution

Treatments execute when their inputs arrive, not according to a predefined schedule. Parallel execution, fan-out, and synchronization are expressed as connections in the program graph. There is no need to explicitly mark jobs as `parallel: true` or manage wait conditions in imperative code, concurrency is a natural consequence of the data flow topology.

### Static Validation

The entire program, its types, connections, and configuration, is validated before any execution begins. Type mismatches, missing connections, and invalid configurations are caught at startup, not discovered halfway through a 20-minute build when a downstream job fails to receive its expected input.

### Deep Debuggability

Because the execution model has a well-defined topology of treatments connected by typed streams, Cadence.CI can observe inputs, outputs, and intermediate state at each node in the graph. This is what makes [treatment-level debugging](/en/docs/how-it-works/general#monitoring-and-debugging) possible, something that is structurally impossible in script-based pipelines, where there is no concept of "the data flowing between step A and step B."

## Summary

| | YAML Config | Imperative Script | Mélodium |
|---|---|---|---|
| Data passing | Artifact upload | Manual serialization | Typed streams |
| Parallelism | Job-level | Explicit async | Topology-driven |
| Distribution | Not native | Manual coordination | Built into the language |
| Validation | At runtime | At runtime | At startup (static) |
| Debuggability | Flat logs | Flat logs | Per-treatment I/O tracing |

### Cloud Integration

> How Cadence.CI integrates with cloud providers so runners execute inside your own cloud project.

Source: https://cadence.ci/en/docs/how-it-works/clouds
Preferred fetch: https://cadence.ci/en/docs/how-it-works/clouds.md

**Cadence.CI** integrates directly with cloud providers so that Mélodium runners are deployed and execute entirely within your own cloud project, keeping your data within infrastructure you control.

## How It Works

When you connect a cloud provider account, Cadence.CI uses the access credentials you supply to provision and manage runner instances on your behalf. The runners remain inside your project's network and talk directly to each other, while Cadence.CI handles orchestration from the outside.

```mermaid
sequenceDiagram
  participant Pipeline as Mélodium Pipeline
  participant Cadence as Cadence.CI
  participant Cloud as Your Cloud Project

  Pipeline->>Cadence: Request runner spawn
  Cadence->>Cloud: Provision VM / instance (via your credentials)
  Cloud-->>Cadence: Instance ready
  Cadence-->>Pipeline: Runner available
  Pipeline->>Cloud: Distribute work directly to runner
  Cloud-->>Pipeline: Logs + results
  Pipeline->>Cadence: Job complete, terminate runner
  Cadence->>Cloud: Destroy instance
```

## Setup Steps

1. **Provide access credentials**: give Cadence.CI the access keys or service account needed to provision compute in your cloud project. Required permissions vary by provider and are documented on each provider's setup page.
2. **Infrastructure configuration**: Cadence.CI automatically configures the required networking and instance parameters within your project.
3. **Runner deployment**: when a pipeline runs, Mélodium runners are deployed directly inside your cloud environment.
4. **Direct execution**: pipeline steps run inside your infrastructure, with direct access to co-located resources over your own network.

## Benefits

- **Performance**: direct execution within your infrastructure eliminates unnecessary network hops between pipeline steps and your resources.
- **Security**: data remains within your cloud environment throughout execution.
- **Cost efficiency**: runners use your existing quota and billing directly.
- **Compliance**: data residency and regulatory requirements are met because compute stays within your designated region and project.

## Supported Cloud Providers

Cadence.CI currently supports integration with the following cloud providers:

<div style="display: grid; grid-template-columns: repeat(auto-fill, minmax(150px, 1fr)); gap: 20px; margin: 20px 0;">
  <div style="text-align: center;">
    <div style="min-height: 64px; max-width: 64px; margin: 0 auto; display: flex; align-items: center; justify-content: center;">
      <img src="/img/logos/scaleway-logo.svg" alt="Scaleway" style="max-width: 64px; height: auto; min-height: 64px;">
    </div>
    <p><strong>Scaleway</strong></p>
  </div>
  <div style="text-align: center;">
    <div style="min-height: 64px; max-width: 64px; margin: 0 auto; display: flex; align-items: center; justify-content: center;">
      <img src="/img/logos/aws-logo.svg" alt="AWS" style="max-width: 64px; height: auto; min-height: 64px;">
    </div>
    <p><strong>AWS</strong></p>
  </div>
</div>

Provider-specific setup instructions, required permissions, and supported instance types are documented on each provider's page. Additional providers are on the [roadmap](/en/docs/roadmap#cloud-providers).

### Kubernetes Integration

> Running Mélodium runners as pods inside your own Kubernetes cluster.

Source: https://cadence.ci/en/docs/how-it-works/kubernetes
Preferred fetch: https://cadence.ci/en/docs/how-it-works/kubernetes.md

**Cadence.CI** integrates with Kubernetes so that Mélodium runners are deployed as pods directly within your cluster. Pipeline execution stays inside your infrastructure, using your existing networking, storage, and compute policies.

## How It Works

A lightweight Kubernetes Controller is deployed in your cluster. It watches for runner provisioning requests from Cadence.CI and creates the corresponding pods. When a job completes, it tears down those pods. All interactions with your cluster go exclusively through the controller.

```mermaid
flowchart LR
  cadence["Cadence.CI"]
  controller["Kubernetes Controller\n(in your cluster)"]
  pods["Runner Pods"]

  cadence -->|runner request| controller
  controller -->|create / delete pods| pods
  pods -.->|logs + telemetry| cadence
```

## Setup Steps

1. **Deploy the controller**: install the Cadence.CI Kubernetes Controller into your cluster. It registers itself with Cadence.CI and handles communication between Cadence.CI and your cluster's API server.
2. **Configure cluster access**: the controller uses a service account scoped to just the permissions needed to create and delete runner pods and their supporting `ServiceAccount`/`Role`/`RoleBinding` objects.
3. **Runner deployment**: when a pipeline runs, Mélodium runners are created as pods in your cluster, using the namespace and resource quotas you configure.
4. **Direct execution**: pipeline steps execute inside your cluster, with direct access to cluster-internal services and storage.

## Benefits

- **Security**: data remains within your Kubernetes environment throughout execution.
- **Cost efficiency**: runners use your existing cluster capacity directly.
- **Compliance**: compute stays within your designated cluster, meeting data residency requirements.
- **Scalability**: Kubernetes' scheduler handles pod placement and resource allocation automatically.
- **Self-healing**: if a runner pod is evicted or crashes, Kubernetes reschedules it and Cadence.CI retries the affected work.

## Self-Managed vs. Melodium-Operated Clusters

Clusters registered with Cadence.CI are one of three service modes:

- **Self-managed**: a cluster you own and operate, registered with your own cluster token. This is the model described above, everything runs on your infrastructure.
- **Shared**: a cluster operated by Melodium, available to organizations on eligible plans. Runners still execute as isolated pods with scoped, per-job service accounts, on Melodium infrastructure shared across organizations.
- **Dedicated**: a cluster operated by Melodium and reserved for a single organization.

The pod-level architecture, controller, scoped service accounts, cluster access limited to the controller, is the same across all three modes. Self-managed clusters run entirely within infrastructure you control; shared and dedicated clusters run on infrastructure Melodium operates on your behalf.

## Available Configurations

While Cadence.CI can run on any standard Kubernetes distribution, pre-built cluster configurations are available for specific providers. See the pages in this section for provider-specific setup guides.

## Getting Started

- [Migrate from GitHub Actions](https://cadence.ci/en/docs/github.md): Automated migration from GitHub Actions to Cadence.CI: how to use the migration tool, what gets converted, and how the output is structured.
- [Build a CI/CD Pipeline from Scratch](https://cadence.ci/en/docs/from-scratch/build-a-ci.md): Step-by-step guide to building a pipeline that clones a repo, compiles a binary, and streams the result back.
- [CI/CD Template](https://cadence.ci/en/docs/from-template/cicd.md): Start from the official CI/CD template to get a working pipeline quickly.
- [Deploy on GitHub Actions](https://cadence.ci/en/docs/from-template/on-github.md): Integrate Cadence.CI pipelines with GitHub Actions as the trigger.
- [Deploy on GitLab CI](https://cadence.ci/en/docs/from-template/on-gitlab.md): Integrate Cadence.CI pipelines with GitLab CI as the trigger.
- [Advanced Implementation](https://cadence.ci/en/docs/from-template/advanced-implementation.md): Advanced patterns: detailed treatments, reusable components, and complex pipeline composition.

### Build a CI/CD Pipeline from Scratch

> Step-by-step guide to building a pipeline that clones a repo, compiles a binary, and streams the result back.

Source: https://cadence.ci/en/docs/from-scratch/build-a-ci
Preferred fetch: https://cadence.ci/en/docs/from-scratch/build-a-ci.md

This guide walks through building a CI/CD pipeline from scratch using Cadence.CI and the Mélodium language. By the end, you will have a working pipeline that clones a repository, compiles a binary, and streams the result back to your local machine.

> [!NOTE]
>
> You need [Mélodium](https://melodium.tech/en/download) version `0.10.0` or greater installed.  
> For a deeper introduction to the Mélodium language, see the [Mélodium Language Book](https://doc.melodium.tech/book/en/).

## Create the Project

Start by scaffolding a new Mélodium program:

```sh
melodium new my_cicd
```

Then open `my_cicd/Compo.toml` and add the following dependencies:

```toml
[dependencies]
std = "0.10.0"
cicd = "0.10.0"
fs = "0.10.0"
process = "0.10.0"
work = "0.10.0"
```

These packages provide the standard library, CI/CD runner primitives, filesystem access, process management, and resource definitions.

## Define the Treatment

A **treatment** in Mélodium is a named unit of work with typed inputs, outputs, and dependencies. Open `my_cicd/lib-root.mel` and declare the `buildSoftware` treatment:

```rust
use cicd/runners::CicdDispatchEngine
use cicd/runners::CicdRunnerEngine

treatment buildSoftware[cicd: CicdDispatchEngine]()
  input trigger:   Block<void>
  output finished: Block<void>
  output binary:   Stream<byte>
  model runner: CicdRunnerEngine()
{
    
}
```

Breaking down the signature:

- `[cicd: CicdDispatchEngine]`, the dispatcher model that manages runner provisioning ([docs](https://doc.melodium.tech/latest/en/cicd/runners/CicdDispatchEngine.html)).
- `input trigger: Block<void>`, a signal that starts the build.
- `output finished: Block<void>`, a signal emitted when the build completes.
- `output binary: Stream<byte>`, a typed byte stream carrying the compiled binary.
- `model runner: CicdRunnerEngine()`, the runner model this treatment will use ([docs](https://doc.melodium.tech/latest/en/cicd/runners/CicdRunnerEngine.html)).

<div className="place-content-center p-3 flex">
<img src="/img/scratch_buildSoftware_outside_light.png" className="dark:hidden rounded shadow"/>
<img src="/img/scratch_buildSoftware_outside_dark.png" className="hidden dark:block rounded shadow"/>
</div>

## Define the Steps

Inside the treatment body, declare three steps that will run sequentially on the runner: installing tools, cloning the repository, and building the binary.

```rust
use cicd/steps::stepOn
use process/command::|raw_commands
/* … */

install: stepOn[runner=runner](
    name="install",
    executor_name="ubuntu",
    commands=|raw_commands([
        "apt-get update",
        "apt-get install -y gcc"
    ])
)

clone: stepOn[runner=runner](
    name="clone",
    executor_name="ubuntu",
    commands=|raw_commands([
        "git clone https://github.com/niwasawa/c-hello-world.git"
    ])
)

build: stepOn[runner=runner](
    name="build",
    executor_name="ubuntu",
    commands=|raw_commands([
        "gcc c-hello-world/hello.c",
        "mv a.out /mnt/data/executable"
    ]),
    out_filesystem="data",
    out_file="executable"
)
```

All three steps run on the executor named `"ubuntu"` from `runner`. The `build` step additionally streams the compiled file back via the `out_file` parameter, see [`stepOn` documentation](https://doc.melodium.tech/latest/en/cicd/steps/stepOn.html) for the full reference.

<div className="place-content-center p-3 flex">
<img src="/img/scratch_makestep_light.png" className="dark:hidden rounded shadow"/>
<img src="/img/scratch_makestep_dark.png" className="hidden dark:block rounded shadow"/>
</div>

## Connect the Steps

Steps are connected by declaring data flows between their inputs and outputs. The `install` and `clone` steps can run in parallel; `build` waits for both to complete before starting.

```rust
use std/flow::waitBlock
/* … */

awaitPrepare: waitBlock<void>()

install.success -> awaitPrepare.a
clone.success ---> awaitPrepare.b

awaitPrepare.awaited -> build.trigger,finished -> Self.finished
                        build.data -------------> Self.binary
```

`waitBlock` is a synchronization primitive that emits `awaited` only after both `a` and `b` have received a value. Once `build` completes, `finished` and `binary` are forwarded to the treatment's own outputs.

<div className="place-content-center p-3 flex">
<img src="/img/scratch_assemble_light.png" className="dark:hidden rounded shadow"/>
<img src="/img/scratch_assemble_dark.png" className="hidden dark:block rounded shadow"/>
</div>

## Provision the Runner

The steps above run on a runner, but the runner itself must be set up and torn down within the treatment. Add `setupRunner` and `stopRunner` calls and connect them to the step lifecycle:

```rust
use cicd/runners::setupRunner
use cicd/runners::stopRunner
use work/resources/arch::|amd64
use work/resources::|container
use work/resources::|mount
use work/resources::|volume
/* … */

setupRunner[dispatcher=cicd, runner=runner](
  cpu=200,
  memory=100,
  storage=100,
  name="builder",
  volumes=[|volume("data", 30)],
  containers=[|container("ubuntu", 1000, 1000, 1000, |amd64(), [|mount("data", "/mnt/data")], "ubuntu:latest", _)]
)
stopRunner[runner=runner]()

Self.trigger -> setupRunner.trigger,ready -> install.trigger
                setupRunner.ready ---------> clone.trigger
                                             build.finished -> stopRunner.trigger
```

The runner is started when the treatment is triggered, `install` and `clone` start as soon as it is ready, and `stopRunner` is called after `build` finishes. The runner is never idle longer than necessary.

<div className="place-content-center p-3 flex">
<img src="/img/scratch_setuprunner_light.png" className="dark:hidden rounded shadow"/>
<img src="/img/scratch_setuprunner_dark.png" className="hidden dark:block rounded shadow"/>
</div>

## Full Treatment

Putting it all together:

```rust
use cicd/runners::CicdDispatchEngine
use cicd/runners::CicdRunnerEngine
use cicd/runners::setupRunner
use cicd/runners::stopRunner
use cicd/steps::stepOn
use process/command::|raw_commands
use std/flow::waitBlock
use work/resources/arch::|amd64
use work/resources::|container
use work/resources::|mount
use work/resources::|volume

treatment buildSoftware[cicd: CicdDispatchEngine]()
  input trigger:   Block<void>
  output finished: Block<void>
  output binary:   Stream<byte>
  model runner: CicdRunnerEngine()
{
    setupRunner[dispatcher=cicd, runner=runner](
        cpu=200,
        memory=100,
        storage=100,
        name="builder",
        volumes=[|volume("data", 30)],
        containers=[|container("ubuntu", 1000, 1000, 1000, |amd64(), [|mount("data", "/mnt/data")], "ubuntu:latest", _)]
    )
    stopRunner[runner=runner]()

    Self.trigger -> setupRunner.trigger,ready -> install.trigger
                    setupRunner.ready ---------> clone.trigger
                                                 build.finished -> stopRunner.trigger

    install: stepOn[runner=runner](
        name="install",
        executor_name="ubuntu",
        commands=|raw_commands([
            "apt-get update",
            "apt-get install -y gcc"
            ])
    )
    clone: stepOn[runner=runner](
        name="clone",
        executor_name="ubuntu",
        commands=|raw_commands([
            "git clone https://github.com/niwasawa/c-hello-world.git"
        ])
    )
    build: stepOn[runner=runner](
        name="build",
        executor_name="ubuntu",
        commands=|raw_commands([
            "gcc c-hello-world/hello.c",
            "mv a.out /mnt/data/executable"
        ]),
        out_filesystem="data",
        out_file="executable"
    )

    awaitPrepare: waitBlock<void>()

    install.success -> awaitPrepare.a
    clone.success ---> awaitPrepare.b

    awaitPrepare.awaited -> build.trigger,finished -> Self.finished
                            build.data -------------> Self.binary
}
```

## Create the Entrypoint

A treatment cannot be run directly, it needs an entrypoint that wires it to the outside world. Add a `runBuild` treatment to `my_cicd/lib-root.mel`:

```rust
use fs/local::writeLocal
use std/engine/util::startup

treatment runBuild(var output_file: string = "./executable")
  model cicd: CicdDispatchEngine(location="compose", api_token="")
{
    startup()

    buildSoftware[cicd=cicd]()
    writeLocal(path=output_file)

    startup.trigger -> buildSoftware.trigger,binary -> writeLocal.data
}
```

Then declare it as the program's entrypoint in `my_cicd/Compo.toml`:

```toml
[entrypoints]
main = "my_cicd::runBuild"
```

## Run

```sh
melodium my_cicd/Compo.toml
```

A file named `executable` will appear in the current directory once the pipeline completes.

> [!NOTE]
>
> The `CicdDispatchEngine` is configured with `location="compose"` here, which uses Podman Compose or Docker Compose to provision runners locally. For production use with Cadence.CI, set `location` to your configured cluster and provide the appropriate `api_token`. See the [`CicdDispatchEngine` documentation](https://doc.melodium.tech/latest/en/cicd/runners/CicdDispatchEngine.html).

## Full Program

Download the [complete program](/downloads/my_cicd.zip) for reference.

### CI/CD Template

> Start from the official CI/CD template to get a working pipeline quickly.

Source: https://cadence.ci/en/docs/from-template/cicd
Preferred fetch: https://cadence.ci/en/docs/from-template/cicd.md

Cadence.CI relies on the Mélodium technology to provide powerful and efficient service. This tutorial explains how to create a detailed CI/CD with Mélodium.

For CI/CD within existing services, Github and GitLab integrations are explained in next sections.

> [!NOTE]
>
> You need [Mélodium](https://melodium.tech/en/download) version `0.10.0` or greater to be installed.

## Create a Mélodium CI/CD project

At the root of git repository, run command `melodium new --template cicd --path .melodium-ci cicd`.
A folder `.melodium-ci/` is now created, containing the base code for a working CI.

In this folder are three files:
- `Compo.toml`
- `lib-root.mel`
- `advanced.mel`

The `Compo.toml` file contains the configuration of the CI/CD program.
`lib-root.mel` contains the CI/CD program itself, and `advanced.mel` the same program but implemented in an advanced way (ignored in this page, see [Advanced Implementation](advanced-implementation)).

Within `lib-root.mel` is the `main` treatment, that is designated as the main entrypoint by the base configuration.
There is no requirement for a program to have such a main entrypoint, different ones may be used for different modes of works.

The `main` treatment contains all the base elements to make the CI/CD working:
- some parameters to manage data exchange outside of the CI/CD process,
- a [`CicdDispatchEngine`](https://doc.melodium.tech/latest/en/cicd/runners/index.html) to manage work dispatch among different services and runners,
- treatments such as [`startup`](https://doc.melodium.tech/latest/en/std/engine/util/startup.html), `build`, and `test`.

[`startup`](https://doc.melodium.tech/latest/en/std/engine/util/startup.html) treatment is provided by the Mélodium standard library to trigger anything from the very beginning of the program.


<img src="/img/main_simple_light.png" className="dark:hidden rounded shadow"/>
<img src="/img/main_simple_dark.png" className="hidden dark:block rounded shadow"/>


## CI/CD Implementation

The `build` and `test` treatments are based on [`simpleStep`](https://doc.melodium.tech/latest/en/cicd/naive/simpleStep.html) and [`simpleStepWithInput`](https://doc.melodium.tech/latest/en/cicd/naive/simpleStepWithInput.html).

Both takes the [`CicdDispatchEngine`](https://doc.melodium.tech/latest/en/cicd/runners/index.html) model, and an input `trigger` signal.

```rust
build: simpleStep[cicd=cicd](
    name="build",
    image="ubuntu:noble",
    commands=|raw_commands([
    "apt-get update",
    "apt-get install -y git",
    "git config --global url.https://.insteadOf  git://",
    |format("git clone --branch {repository_clone_ref} --depth 1 {repository_clone_url} project",
        |map([
            |entry("repository_clone_ref", repository_clone_ref),
            |entry("repository_clone_url", repository_clone_url)
        ])
    ),
    "sh -c \"cd project/ ; ls -l --almost-all | tee files-list.txt\"",
    "mv project/files-list.txt /mnt/data/"
    ]),
    out_file="files-list.txt"
)
```

```rust
test: simpleStepWithInput[cicd=cicd](
    name="test",
    image="alpine",
    in_file="list.txt",
    commands=[
        |command("test", ["-s", "/mnt/data/list.txt"]),
        |command("cat", ["/mnt/data/list.txt"])
    ]
)
```

They both take some parameters:
- `name`, a string naming the step itself, used in logs and reports;
- `image`, the container image to use;
- `pull_secret`, the (optional) secret to use to pull the container image;
- `commands`, the list of commands to run;
- `out_file`, the (optional) file to stream as output `data`.

Few parameters are available to configure more precisely a step:
- `memory`, memory (in mebibytes) dedicated to container;
- `cpu`, amount of CPUs (in millicores);
- `storage`, disk space (in mebibytes) at disposal;
- `arch`, designating the hardware architecture on which the step must run (default is ARM64).

> Currently the AMD64/x86_64 [`|amd64()`](https://doc.melodium.tech/latest/en/work/resources/arch/|amd64.html) and ARM64/aarch64 [`|arm64()`](https://doc.melodium.tech/latest/en/work/resources/arch/|arm64.html) architectures are supported.

## Processing commands

The `commands` parameter is a list of commands run on container.

Commands can be specified in multiple ways:
- [`|command()`](https://doc.melodium.tech/latest/en/process/command/|command.html) function, for a finely-detailed command and list of arguments;
- [`|raw_command()`](https://doc.melodium.tech/latest/en/process/command/|raw_command.html) function, for a raw string command;
- [`|raw_commands()`](https://doc.melodium.tech/latest/en/process/command/|raw_commands.html) function, for full list of string commands.

## Triggering and Connecting Steps

The [`simpleStep`](https://doc.melodium.tech/latest/en/cicd/naive/simpleStep.html) and [`simpleStepWithInput`](https://doc.melodium.tech/latest/en/cicd/naive/simpleStepWithInput.html) both provides inputs and outputs:
- input `trigger`, to instanciate container and start the processing;
- output `started`, to signal when commands starts to run;
- output `completed`, to signal successful completion of step;
- output `failed`, to signal failure of step;
- output `finished`, to signal step is finished, whatever it were successful or not;
- output `data`, streaming data from file given in `out_file`.

Also, the `simpleStepWithInput` provides an input `data` to write file `in_file` within container before running commands.

```rust
startup.trigger -> build.trigger,data -> test.data
startup.trigger -----------------------> test.trigger
```

<img src="/img/main_example_light.png" className="dark:hidden rounded shadow"/>
<img src="/img/main_example_dark.png" className="hidden dark:block rounded shadow"/>

## About Dispatch and Distribution

Mélodium dispatch the work among workers located on different containers and machines, depending on the given requirements.
The same unique CI/CD program can run across multiple processes and machines and allows precise synchronization and schedule among heterogenous systems.

A [`CicdDispatchEngine`](https://doc.melodium.tech/latest/en/cicd/runners/CicdDispatchEngine.html) can be configured to dispatch work through cloud API or locally using container composition, independently from where the initial process in running.

The `location` parameter specifies what dispatching method is to use, with either `"api"` (the default) or `"compose"` values, respectively sending dispatch runner requests to the API or spawning it using Podman Compose or Docker Compose. In the case of container composition, requirements satisfaction is subject to machine abilities, especially architecture and total available memory.

> [!NOTE]
>
> `"compose"` distribution can be used in CI/CD services like Github Actions and GitLab CI to make full use of provided runners without relying on additional external runners.

## Execute CI/CD Locally with Remote Distribution

In order to run the CI/CD program, invoke Mélodium with program parameters.
```sh
melodium .melodium-ci/Compo.toml --api_token <YOUR_RUN_API_TOKEN> --output_directory /your/output/directory --repository_clone_url <FULL_CLONE_URL>.git --repository_clone_ref <BRANCH_OR_TAG>
```

Where `YOUR_RUN_API_TOKEN` is a Cadence.CI Run Token. This is executing the CI/CD "main engine" from local computer and distributing the work on distant workers.

All the CI/CD logs are shown in terminal, and data wrote under `/your/output/directory`.

## Execute CI/CD Locally with Local Distribution

If Podman Compose or Docker Compose is installed locally, it is possible to launch the CI/CD with local distribution:
```sh
melodium .melodium-ci/Compo.toml --work_location compose --api_token <YOUR_RUN_API_TOKEN> --output_directory /your/output/directory --repository_clone_url <FULL_CLONE_URL>.git --repository_clone_ref <BRANCH_OR_TAG>
```

Be aware that the CI/CD is then constrained to host machine abilities, especially in terms of memory and architecture.

> [!NOTE]
>
> Container Runtime service must be running. This is the default with Docker. On Podman, the `podman service` should be launched (i.e. `podman system service --time 0 unix:///run/user/1000/podman/podman.sock`).

## Execute CI/CD on Service

CI/CD is executable on any service able to run Mélodium. Most common ones are Github and GitLab, for which detailed procedures are given in next sections.

### Advanced Implementation

> Advanced patterns: detailed treatments, reusable components, and complex pipeline composition.

Source: https://cadence.ci/en/docs/from-template/advanced-implementation
Preferred fetch: https://cadence.ci/en/docs/from-template/advanced-implementation.md

Here is an explanation of the advanced implementation of CI/CD, using more detailed treatments and tooling.
`main` acts the same as in root, `build` and `test` treatments are from `advanced.mel` file and contains CI/CD implementation.

## CI/CD implementation

The `build` and `test` treatments are implemented the same way: they require to setup a runner, on which steps are distributed.
Their basic implementation is given as naive working example.

Both takes the [`CicdDispatchEngine`](https://doc.melodium.tech/latest/en/cicd/runners/index.html) model, and an input `trigger` signal. [`CicdDispatchEngine`](https://doc.melodium.tech/latest/en/cicd/runners/index.html) and input `trigger` are used to require a new distributed runner [`CicdRunnerEngine`](https://doc.melodium.tech/latest/en/cicd/runners/index.html) through [`setupRunner`](https://doc.melodium.tech/latest/en/cicd/runners/setupRunner.html) as soon as it is useful to get one ready.

```rust
treatment build[cicd: CicdDispatchEngine](repository_clone_url: string, repository_clone_ref: string)
  model runner: CicdRunnerEngine()
  input trigger: Block<void>
  output data:   Stream<byte>
{
    setupRunner[
        dispatcher=cicd,
        runner=runner
    ](
        name="build",
        cpu=100, // mCPU
        memory=500, // MB
        storage=1000, // MB
        volumes=[
            // Volumes made available
            |volume("build-result", 30 /* MB */)
        ],
        containers=[
            |container("ubuntu", // Container name
                1000, // mCPU
                200, // MB
                8000, // MB
                |amd64(),
                [ // Mount points
                    |mount("build-result", "/mounted/result")
                ],
                "ubuntu:noble", // Image name
                _)
        ]
    )
    gitClone: stepOn[runner=runner](
        executor_name="ubuntu", // Use the “ubuntu” container
        environment=|wrap<Environment>(|environment(|map([/* No env variables */]), "/root", false, false)),
        commands=[
            |command("apt-get", ["update"]),
            |command("apt-get", ["install", "-y", "git"]),
            |command("git", ["config", "--global", "url.https://.insteadOf", "git://"]),
            |command("git", ["clone", "--branch", repository_clone_ref, "--depth", "1", repository_clone_url, "project"])
        ]
    )
    makeList: stepOn[runner=runner](
        executor_name="ubuntu", // Use the “ubuntu” container
        environment=|wrap<Environment>(|environment(|map([]), "/root/project", false, false)),
        commands=|raw_commands([
            "sh -c \"ls -l --almost-all | tee files-list.txt\"",
            "mv files-list.txt /mounted/result/"
        ]),
        out_filesystem="build-result",
        out_file="files-list.txt"
    )
    stopRunner[runner=runner]()

    Self.trigger -> setupRunner.trigger,ready -> gitClone.trigger,completed -> makeList.trigger,finished -> stopRunner.trigger
                                                                               makeList.data -------------> Self.data
}
```

<img src="/img/main_advanced_light.png" className="dark:hidden rounded shadow"/>
<img src="/img/main_advanced_dark.png" className="hidden dark:block rounded shadow"/>

## Setup runner

[`setupRunner`](https://doc.melodium.tech/latest/en/cicd/runners/setupRunner.html) takes different parameters, the main ones are:
- `name`, a string with which all logs will be marked;
- `memory`, memory (in mebibytes) dedicated to the Mélodium engine;
- `cpu`, amount of CPUs (in millicores) the Mélodium engine must have;
- `storage`, disk space (in mebibytes) the Mélodium engine have at disposal;
- `volumes`, array of volumes the Mélodium engine and containers can share on the runner;
- `containers`, list of containers that are available to run steps on the runner.

Volumes are basically labels associated with size (in mebibytes), and can be mounted inside containers to share data with them.
Containers are defined by the following:
```rust
|container(name, memory, cpu, storage, arch, mounts, image, pull_secret)
```
- `name` being the designated name with which the container can be adressed as executor;
- `memory`, `cpu`, and `storage` having the same meaning than for the Mélodium engine;
- `arch` designating the hardware architecture on which the container must run;
- `mounts` being an array of mounting points for defined volumes within the container filesystem;
- `image` the container image to use as base for the container;
- `pull_secret` the (optional) secret to use to pull the container image.

> The Mélodium engine itself can be quite frugal in resources as work in CI/CD is usually done within containers, leaving only the orchestration and data streaming work, as such, 0.1 CPU and 100 MiB are good enough as default values.

> Currently the AMD64/x86_64 `|amd64()` and ARM64/aarch64 `|arm64()` architectures are supported, and all the containers in the same runner must use the same architecture.

> All mounted volumes inside containers must fit within the container storage itself. While CPU and memory values are cumulative among the main engine and containers, requiring the runner to have the sum of all the required capacities, the storage space corresponding to volumes are shared and not duplicated between containers.

## Run steps

On every runner an arbitrary number of steps can be applied using the [`stepOn`](https://doc.melodium.tech/latest/en/cicd/steps/stepOn.html) and [`stepOnWithInput`](https://doc.melodium.tech/latest/en/cicd/steps/stepOnWithInput.html) treatments.
These treatments takes a [`CicdRunnerEngine`](https://doc.melodium.tech/latest/en/cicd/runners/index.html), on which work will be done, according to the following logic:
1. inputting data file (for [`stepOnWithInput`](https://doc.melodium.tech/latest/en/cicd/steps/stepOnWithInput.html)),
1. processing commands,
1. outputting data file.

### Inputting data

[`stepOnWithInput`](https://doc.melodium.tech/latest/en/cicd/steps/stepOnWithInput.html) have two parameters setting up what data file is wrote: `in_filesystem` and `in_file` respectively tells what volume and what file name are filled with data coming from `data` input.

Here the file `"list.txt"` is wrote on filesystem volume `"tested-data"` and accessible on the mounting point `"/mounted/data/"` of executor `"alpine"`:
```rust
makeTest: stepOnWithInput[runner=runner](
    executor_name="alpine",
    in_filesystem="tested-data",
    in_file="list.txt",
    commands=[
        |command("test", ["-s", "/mounted/data/list.txt"]),
        |command("cat", ["/mounted/data/list.txt"])
    ]
)
```

### Processing commands

The `commands` parameter is a list of commands run on executor designated by `executor_name` within optionally-defined `environment`.

Commands can be specified in multiple ways:
- [`|command()`](https://doc.melodium.tech/latest/en/process/command/|command.html) function, for a finely-detailed command and list of arguments;
- [`|raw_command()`](https://doc.melodium.tech/latest/en/process/command/|raw_command.html) function, for a raw string command;
- [`|raw_commands()`](https://doc.melodium.tech/latest/en/process/command/|raw_commands.html) function, for full list of string commands.

`environment` can also be given, to specify additionnal environment variables or working directory.
The environemnt is applied on all commands of a given step.

```rust
gitClone: stepOn[runner=runner](
    executor_name="ubuntu",
    environment=|wrap<Environment>(|environment(|map([]), "/root", false, false)),
    commands=[
        |command("apt-get", ["update"]),
        |command("apt-get", ["install", "-y", "git"]),
        |command("git", ["config", "--global", "url.https://.insteadOf", "git://"]),
        |command("git", ["clone", "--branch", repository_clone_ref, "--depth", "1", repository_clone_url, "project"])
    ]
)
```

### Outputting data

[`stepOn`](https://doc.melodium.tech/latest/en/cicd/steps/stepOn.html) and [`stepOnWithInput`](https://doc.melodium.tech/latest/en/cicd/steps/stepOnWithInput.html) treatments both allows to output any data. `out_filesystem` and `out_file` specify what volume and file is streamed after step commands.

Here the file `"files-list.txt"` is streamed from volume `"build-result"` after commands are run:
```rust
makeList: stepOn[runner=runner](
    executor_name="ubuntu",
    environment=|wrap<Environment>(|environment(|map([]), "/root/project", false, false)),
    commands=|raw_commands([
        "sh -c \"ls -l --almost-all | tee files-list.txt\"",
        "mv files-list.txt /mounted/result/"
    ]),
    out_filesystem="build-result",
    out_file="files-list.txt"
)
```

## Execute CI/CD Locally

In order to run the CI/CD program, invoke Mélodium with program parameters.
```sh
melodium run .melodium-ci/Compo.toml advanced --api_token <YOUR_RUN_API_TOKEN> --output_directory /your/output/directory --repository_clone_url <FULL_CLONE_URL>.git --repository_clone_ref <BRANCH_OR_TAG>
```

Where `YOUR_RUN_API_TOKEN` is a Cadence.CI Run Token. This is executing the CI/CD "main engine" from local computer and distributing the work on distant workers.

All the CI/CD logs are shown in terminal, and data wrote under `/your/output/directory`.

## Deploying Clusters

- [Self-Managed Cluster](https://cadence.ci/en/docs/clusters/self-managed.md): Deploy a self-managed Mélodium cluster on your own Kubernetes infrastructure using the Kubernetes Controller.
- [Scaleway Cluster](https://cadence.ci/en/docs/clusters/scaleway.md): All-in-one Terraform module to deploy a Mélodium cluster on Scaleway.

### Self-Managed Cluster

> Deploy a self-managed Mélodium cluster on your own Kubernetes infrastructure using the Kubernetes Controller.

Source: https://cadence.ci/en/docs/clusters/self-managed
Preferred fetch: https://cadence.ci/en/docs/clusters/self-managed.md

It is possible to deploy self-managed clusters with Mélodium and Kubernetes.  
A Kubernetes Controller is available to set up interaction between Kubernetes and Mélodium Distribution API.

## Available configurations

While any Kubernetes provider should be able to run a Mélodium Cluster, some configurations are available as Terraform modules to build up and manage fully working clusters. Those are available in following pages.

### Scaleway Cluster

> All-in-one Terraform module to deploy a Mélodium cluster on Scaleway.

Source: https://cadence.ci/en/docs/clusters/scaleway
Preferred fetch: https://cadence.ci/en/docs/clusters/scaleway.md

Mélodium provides an all-in-one Terraform module to deploy clusters on [Scaleway](https://www.scaleway.com/):  
[`scaleway-kubernetes-cluster`](https://registry.terraform.io/modules/melodium-tech/scaleway-kubernetes-cluster/melodium).

> [!NOTE]
>
> You need Terraform to be installed first to follow those steps, take a look at [Terraform.io](https://www.terraform.io/) if you don't have it yet.

## Authenticate with Scaleway

To run the Scaleway Terraform Provider, `SCW_ACCESS_KEY` and `SCW_SECRET_KEY` environment variables must be set up.  
Refer to the [Authentication](https://registry.terraform.io/providers/scaleway/scaleway/latest/docs#authentication) section of Scaleway Terraform Provider to proceed.

## Authenticate with Cluster Token

In your account, go to _Tokens_ > _Cluster Tokens_ and _New Token_ to generate a new token usable for clusters.

## Create Terraform Configuration

Create a new directory and write into a file named `main.tf` the following content:
```terraform

module "scaleway-kubernetes-cluster" {
  source  = "melodium-tech/scaleway-kubernetes-cluster/melodium"
  version = "0.0.3"
  
  // Project UUID (available in Scaleway Console near project name)
  project_id = "<YOUR PROJECT ID>" 
  
  cluster_name = "beautiful-test-cluster"
  cluster_description = "Cluster test on Scaleway"
  cluster_token = "<YOUR CLUSTER TOKEN>"

  /*
  Other available variables:

  region = "fr-par"
  zone = "fr-par-2"
  cluster_work_pools = {
    "arm-4C-16G" = {
      node_type = "COPARM1-4C-16G" // Scaleway Node Type
      volume_size = 80 // Disk in GB
      min_size = 0 // Minimal number of machines present at any time in this pool
      max_size = 4 // Absolute maximum number of machines in this pool
    },
    "amd-4C-16G" = {
      node_type = "GP1-XS"
      volume_size = 80
      min_size = 0
      max_size = 4
    }
  }
  */
  
}

```

## Run Terraform

Run the following commands in a terminal within the folder containing `main.tf`:

```sh
terraform init
terraform apply
```

Once operation is complete, your new cluster is ready and your Mélodium distributed jobs will be sent to it.

## Delete the cluster

Once you want to delete the cluster, run:
```sh
terraform destroy
```
This will remove all the resources associated with the cluster, and disable it on the Mélodium Distribution API.

## Blog

- [Blog](https://melodium.tech/en/blog): Mélodium and Cadence CI news, articles and updates.
## Produit (français)

- [Accueil](https://cadence.ci/fr.md): Présentation de Cadence.CI : supprimer les barrières d'intégration, réduire les coûts CI, activer le DevOps et MLOps complets.
- [Cas d'usage](https://cadence.ci/fr/use-cases.md): Cas concrets : pipelines IA, débogage approfondi avec inspection des flux, vibe coding, collaboration multi-domaine.
- [Tarifs](https://cadence.ci/fr/pricing.md): Plans et tarifs : niveaux Access (gratuit), Pro et Enterprise avec crédits de calcul et options de cluster.

### Accueil

> Présentation de Cadence.CI : supprimer les barrières d'intégration, réduire les coûts CI, activer le DevOps et MLOps complets.

Source: https://cadence.ci/fr
Preferred fetch: https://cadence.ci/fr.md

Cadence.CI vous offre des pipelines d’intégration observables, robustes et sécurisés. Un contrôle total de l’exécution à la livraison.
Vérifié avant toute exécution, sur une infrastructure que vous possédez déjà.

 Commencez gratuitement Voir comment ça marche

Exécutez les intégrations là où il faut

Utilisez le fournisseur que vous souhaitez. Restez proche de votre infrastructure. Changez de localisation en toute fluidité.

Orchestrez avec des règles fines et claires

Mécanismes d'orchestration entièrement personnalisables. Concurrence illimitée.

Obtenez des informations détaillées

Accès aux données et flux granulaires. Analysez et reproduisez. Assurez la conformité.

Évitez les ralentissements des projets et les coûts cachés

Sécurité par conception. Améliorez les retours des développeurs et des produits. Accélérez livraison et innovation.

### Cas d'usage

> Cas concrets : pipelines IA, débogage approfondi avec inspection des flux, vibe coding, collaboration multi-domaine.

Source: https://cadence.ci/fr/use-cases
Preferred fetch: https://cadence.ci/fr/use-cases.md

### Vérifié avant l’exécution

Fini le débogage à coups de push

Tout le pipeline, les types, les connexions, chaque paramètre, est vérifié avant qu’un seul runner ne
soit provisionné. Un pipeline mal formé ne devient jamais une facture, et une étape mal alignée ne
vous coûte jamais les dix minutes qu’il faut pour le découvrir sur un runner.

### Pipelines IA

Router, borner, et prouver où vont les données

Envoyez chaque requête vers le modèle qui a réellement besoin d’y répondre, et gardez visible dans le
pipeline lui-même, plutôt que dans un document de politique, la frontière entre ce qui s’exécute
localement et ce qui atteint un modèle distant.

### Projets souverains

Indépendance technologique et légale

Cadence.CI fonctionne sur des technologies libres et open source, et nos partenaires d’infrastructure
sont incorporés et situés dans l’Union européenne, avec des clusters gérés à Paris, Amsterdam et
Varsovie. Si nous disparaissions demain, vous perdriez un tableau de bord, pas votre capacité à
construire vos logiciels: le moteur ne dépend de nous à l’exécution en rien.

#### Interopérabilité des plateformes

Fonctionne localement, sur n'importe quel cloud, où vous voulez

S'intègre à n'importe quel fournisseur cloud et n'importe quelle localisation, se distribue sur différentes plateformes sans limitation. Cadence.CI ne dépend d'aucun fournisseur ni système spécifique.

#### Coupure totale

Fonctionne en isolation physique

Permet aux pipelines de fonctionner totalement isolés du monde extérieur. Aucun échange de données ni dépendance d'exécution externe. Exécutez-le sur votre infrastructure locale, dans votre cloud privé dédié, ou sur votre réseau isolé.

#### Débogage en profondeur

Ne vous fiez pas qu'aux journaux

Obtenez une vision complète de ce qui se passe, d'où viennent et où vont les flux, analysez les véritables événements de débogage.

#### Systèmes et infrastructures spécifiques

Gérez l'intégration sur des systèmes spécifiques à votre industrie

Linux, macOS et Windows, avec des binaires publiés pour x86-64, ARM64 et i686. s390x et RISC-V sont compilés et vérifiés dans notre propre intégration continue aujourd'hui ; demandez-nous si votre infrastructure a besoin de l'un des deux comme cible publiée.

#### Équipes en croissance

Impliquez plus de monde sans rien casser

Permettre à beaucoup de monde de collaborer sur des projets tout en s'assurant que tout continue de fonctionner est un défi. Cadence.CI assure la continuité de vos équipes et projets en pleine croissance, sans casse inattendue.

#### Vibe Code

Exprimez ce que vous voulez

Construisez en accord avec vos projets vibe. Créez des processus d'intégration que vous pouvez voir. Comprenez ce qu'ils font. Expliquez-les aux autres.

## Vous voulez en savoir plus?

Chaque projet est unique, et Cadence.CI n’aura pas le même impact à chaque intégration.
Si vous ressentez un besoin d’accompagnement ou d’informations supplémentaires? N’hésitez pas à nous contacter.

### Tarifs

> Plans et tarifs : niveaux Access (gratuit), Pro et Enterprise avec crédits de calcul et options de cluster.

Source: https://cadence.ci/fr/pricing
Preferred fetch: https://cadence.ci/fr/pricing.md

## Tarification

Accélérer l'intégration et la livraison

Pas de plafond de minutes, pas de limite de concurrence qui bloque votre équipe, pas de runners qui restent inactifs. Cadence.CI tourne sur une infrastructure que vous payez déjà, exploitée pleinement plutôt que rationnée.

### Accès

Gratuit

Démarrez en quelques minutes. Utilisez vos runners existants sans changer votre infrastructure.

- Connectez vos comptes cloud et lancez des VMs directement. Sans limite de minutes, payez à l'usage au tarif de votre fournisseur.
- Logs et événements de débogage pour chaque exécution
- S'intègre nativement dans vos dépôts GitHub et GitLab
- Fonctionne sur vos runners GitHub et GitLab existants, sans modification d'infrastructure
- Aucune infrastructure à migrer: gardez vos runners actuels et évaluez sans risque

 S'inscrire

### Base

 Accès Anticipé

 $35 par utilisateur / mois

hors taxes, facturé annuellement

Connectez vos clusters et réduisez les coûts d'infrastructure jusqu'à ÷10 par rapport à GitHub Actions.

- Tout du plan Accès
- Ordonnancement intelligent pour éliminer le temps de calcul inutilisé
- Rôles Admin & Utilisateur pour le contrôle d'accès de l'équipe
- 120 jours d'historique pour le débogage et la conformité
- Connectez vos projets cloud pour exécuter au plus proche et réduire les coûts
- Réduisez les dépenses d'infrastructure inactive grâce au déploiement à la demande

 Commencer

 Le Plus Populaire

### Pro

 Accès Anticipé

 $62 par utilisateur / mois

hors taxes, facturé annuellement

Gouvernance complète pour les équipes en croissance. Contrôle des coûts granulaire, historique d'audit et hébergement souverain.

- Tout du plan Base
- Politiques de machines granulaires pour optimiser les coûts à l'échelle
- Réduisez le temps de débogage grâce à une visibilité fine sur les coûts et l'audit
- Rôles utilisateur configurables avec contrôle d'accès à l'échelle de l'organisation
- Groupes de permissions pour une montée en charge sans rupture
- Webhooks et intégrations d'événements entièrement personnalisables
- Piste d'audit sur 1 an pour la conformité et l'analyse post-incident

 Commencer

### Entreprise

 Sur Demande

Sur Devis

hors taxes, facturé annuellement

Souveraineté maximale pour les environnements réglementés. On-premise, air-gap, échelle illimitée et SLA dédié.

- Tout du plan Pro
- Déploiement air-gap et on-premise pour une souveraineté totale des données
- Clusters entièrement gérés par nos équipes
- Utilisateurs illimités avec structures de rôles personnalisées
- SLA personnalisé et support dédié

Fonctionnalités

Accès

Base

Pro

Entreprise

Intégration Github & GitLab

 Éditeur Visuel de Pipelines

Inspection des Logs et Événements de Débogage

Jobs Concurrents

10,000

Illimité

Illimité

Illimité

Active Users

10

Illimité

Illimité

Illimité

Control Pane

Partagé

Partagé

Dédié

Sur Site

Intégration des Runners Auto-Hébergés

Intégrations Fournisseurs Cloud (Scaleway, AWS)

Connexions de Clusters Kubernetes

Rôles Utilisateurs

Administrateur & Utilisateur

Administrateur & Utilisateur

Rôles Personnalisés

Rôles Personnalisés

Ciblage de Machines par Étape

Groupes de Permissions

Webhooks Personnalisés

Hébergement Dédié et Interne

Validation Fail-Fast & Isolation des Secrets en Mémoire

Rétention des Données

7 Jours

120 Jours

1 Année

Personnalisé

Cadence.CI est plus que des fonctionnalités: c'est une réduction du temps et des coûts

Calculez vos bénéfices avec Cadence.CI

Déterminez les coûts de votre CI/CD actuelle

###

 Développeurs dans votre équipe

5

 Coût salarial mensuel d'un développeur

 Durée typique d'un run CI

30 minutes

###

 Exécutions par développeur par jour

4

 Taux d'échec des exécutions

10%

 Temps de débogage moyen par échec

25 minutes

 Heures de maintenance CI par semaine

4h

###

## Comparatif

 Infrastructure Attente Changement de contexte Débogage Maintenance

## Bénéfices

8.3

Jours de travail récupérés par mois

+$7,114

Montant gagné par mois

0.7

Équivalent temps plein par an

### Mensuels

### Annuels

 Temps gagné par mois par développeur 13 heures, 12 minutes

 Temps gagné par an par développeur 6 jours, 14 heures, 24 minutes

 Jours travaillés gagnés par mois 8.3

 Jours travaillés gagnés par an 99.6

 Montant gagné par mois +$7,114

 Montant gagné par an +$85,363

## Contactez-nous

## Comment ça marche (français)

- [Architecture générale](https://cadence.ci/fr/docs/how-it-works/general.md): Principes fondamentaux : observabilité, collaboration, sécurité. Pipelines distribués via Mélodium avec flux de données, réactions aux événements et gestion des processus.
- [Langage de programmation](https://cadence.ci/fr/docs/how-it-works/programming-language.md): Le langage Mélodium pour définir les pipelines CI/CD : syntaxe, concepts, et différences avec le YAML CI classique.
- [Intégration cloud](https://cadence.ci/fr/docs/how-it-works/clouds.md): Intégration avec les fournisseurs cloud pour que les runners s'exécutent dans votre propre projet cloud.
- [Intégration Kubernetes](https://cadence.ci/fr/docs/how-it-works/kubernetes.md): Exécution des runners Mélodium comme pods dans votre propre cluster Kubernetes.

### Architecture générale

> Principes fondamentaux : observabilité, collaboration, sécurité. Pipelines distribués via Mélodium avec flux de données, réactions aux événements et gestion des processus.

Source: https://cadence.ci/fr/docs/how-it-works/general
Preferred fetch: https://cadence.ci/fr/docs/how-it-works/general.md

**Cadence.CI** est une plateforme DevOps construite autour de trois principes : **l'observabilité**, **la collaboration** et **la sécurité**. Cette page présente l'architecture et les concepts qui sous-tendent la plateforme.

## Technologie centrale

**Cadence.CI** repose sur [Mélodium](https://melodium.tech/) pour implémenter des **pipelines distribués**, en gérant les **flux de données**, les **réactions aux événements** et la **gestion des processus** de manière **scalable**, **reproductible** et **tolérante aux pannes**.

### Les flux de données comme entités de premier ordre

Mélodium traite les flux de données comme l'unité fondamentale du calcul. Ces flux peuvent être distribués, transformés et traités sur plusieurs nœuds, permettant une gestion des données en temps réel et scalable. Ils sont **typés et génériques**, ce qui permet un code sûr et réutilisable pour différents types de données et environnements.

### Programmation événementielle et réactive

Les traitements réagissent aux données ou événements entrants plutôt que de suivre un ordre d'exécution prédéfini. C'est particulièrement utile pour les pipelines d'intégration, l'analyse en temps réel et le traitement distribué des tâches, où l'exécution dépend de la disponibilité des données.

### Support multiplateforme

Le système de distribution de Mélodium fonctionne sur des plateformes variées, des systèmes embarqués contraints aux infrastructures cloud à grande échelle. Des couches d'abstraction gèrent les spécificités des plateformes, permettant aux auteurs de pipelines de se concentrer sur la logique plutôt que sur le déploiement.

## Infrastructure et distribution

Cadence.CI génère dynamiquement des runners sur des **infrastructures et fournisseurs cloud variés**, de manière totalement agnostique.

### Agnosticisme de l'infrastructure

Cadence.CI laisse les utilisateurs libres de choisir et de combiner des environnements cloud et on-premises. Les runners peuvent être déployés sur :

- **Clouds publics** ([Scaleway](https://www.scaleway.com/) et AWS aujourd'hui, d'autres fournisseurs sont prévus)
- **Infrastructures on-premises** (tout cluster Kubernetes, auto-géré ou opéré par Mélodium)
- **Environnements hybrides** (mélangeant cloud et on-prem)

### Génération dynamique des runners

Les runners sont provisionnés à la demande et supprimés à la fin de la tâche :

- **Provisionnement à la demande** : les runners sont générés uniquement lorsque nécessaire, éliminant les coûts liés aux ressources inactives.
- **Auto-scaling** : le système s'adapte en fonction des besoins des pipelines.
- **Runners éphémères** : chaque runner est créé pour une tâche spécifique et détruit après exécution, améliorant à la fois l'efficacité et la posture de sécurité.

### Couche d'abstraction unifiée

Mélodium partage les spécifications des pipelines avec Cadence.CI indépendamment de l'infrastructure sous-jacente. Cadence.CI traduit les requêtes de Mélodium en actions spécifiques au fournisseur, lancer une instance EC2 sur AWS, une instance sur Scaleway, ou un pod sur Kubernetes, tout en présentant une interface cohérente à l'auteur du pipeline.

```mermaid
flowchart TD
  cadence((Cadence.CI))

  subgraph Infra A
    subgraph Runner_1
        mel1[Mélodium]
        containerAa1@{shape: procs, label: "Container"}
        containerAa2@{shape: procs, label: "Container"}
        mel1 --- containerAa1
        mel1 --- containerAa2
    end

    subgraph Runner_2
        mel2[Mélodium]
        containerAb1@{shape: procs, label: "Container"}
        mel2 --- containerAb1
    end

  end

  subgraph Infra B
    subgraph Runner_3
        mel3[Mélodium]
        containerBa1@{shape: procs, label: "Container"}
        containerBa2@{shape: procs, label: "Container"}
        mel3 --- containerBa1
        mel3 --- containerBa2
    end

    subgraph Runner_4
        mel4[Mélodium]
    end

    subgraph Runner_5
        mel5[Mélodium]
    end

  end

  mel0["Mélodium\n(Processus initial)"]

  mel0 -.->|Demande de création| cadence

  cadence -.->|Crée| Runner_1
  cadence -.->|Crée| Runner_2
  cadence -.->|Crée| Runner_3
  cadence -.->|Crée| Runner_4
  cadence -.->|Crée| Runner_5

  mel0 ---|Distribue| mel1
  mel0 ---|Distribue| mel2
  mel0 ---|Distribue| mel3
  mel0 ---|Distribue| mel4
  mel0 ---|Distribue| mel5
```

## Monitoring et débogage

Cadence.CI fournit un **monitoring et un débogage** des exécutions Mélodium, en agrégeant les logs et les données d'exécution des runners, quelle que soit l'infrastructure, cloud, on-prem ou hybride.

### Agrégation des logs et données de débogage

Les runners envoient les logs et les données de débogage à Cadence.CI par blocs au fur et à mesure de l'exécution, ceux-ci apparaissant dans le tableau de bord peu après chaque envoi, et vous pouvez les consulter par exécution, avec un dump complet du programme exécuté.

### Données d'exécution par run

Pour chaque run, Cadence.CI enregistre :

- **État d'exécution** : heures de demande, de début et de fin, statut courant (planification, en cours, terminé, non planifiable) et résultat de succès/échec.
- **Point d'entrée et paramètres** : le point d'entrée exact du traitement et les paramètres d'entrée utilisés pour lancer le run.
- **Ressources demandées** : CPU, mémoire et stockage demandés pour le moteur, les conteneurs et les conteneurs de service du run.

Le débogage au niveau des traitements, la relecture en mode time-travel, les alertes et l'export de métriques figurent sur la [feuille de route](/fr/docs/roadmap#monitoring-et-débogage).

## Organisation et sécurité

### Rôles et invitations

Les utilisateurs appartiennent à une organisation et possèdent un rôle (Admin, Operator ou Lambda) qui définit ce qu'ils peuvent faire, comme gérer les jetons de cluster ou consulter les détails d'un cluster. Les administrateurs peuvent inviter de nouveaux utilisateurs dans l'organisation par e-mail, et les rôles et l'accès s'appliquent au niveau de l'organisation.

Le regroupement en équipes et la délimitation des permissions par projet/runner figurent sur la [feuille de route](/fr/docs/roadmap#organisation-et-sécurité).

### Apportez votre propre infrastructure (BYOI)

Cadence.CI suit un modèle « Apportez votre propre infrastructure » (BYOI) : l'orchestration des pipelines s'exécute sur Cadence.CI, tandis que le calcul s'exécute sur une infrastructure que vous contrôlez, votre propre compte fournisseur de cloud ou votre propre cluster Kubernetes.

```mermaid
flowchart TD
  cadence["Cadence.CI\n(orchestration + observabilité)"]

  subgraph "Votre infrastructure"
    vpc["Réseau privé / VPC / On-Prem"]
    runner1["Runner"]
    runner2["Runner"]
    vpc --- runner1
    vpc --- runner2
  end

  cadence -->|création + coordination| vpc
  runner1 -.->|logs + télémétrie| cadence
  runner2 -.->|logs + télémétrie| cadence
```

Ce modèle garantit :

- **Souveraineté des données** : les données sensibles restent au sein de votre infrastructure privée, et les runners peuvent être placés dans des régions spécifiques pour respecter les exigences de résidence des données (RGPD, CCPA, etc.).
- **Isolation réseau** : les runners peuvent être déployés dans des VPC isolés, des centres de données on-prem ou des environnements air-gapped.
- **Alignement avec la conformité** : en contrôlant l'infrastructure, vous pouvez satisfaire des exigences strictes (HIPAA, PCI DSS, SOC 2, ISO 27001) en utilisant des environnements déjà certifiés.
- **Runners éphémères** : les runners sont de courte durée, ce qui élimine toute surface d'attaque inutilisée.

Les organisations qui préfèrent s'exécuter sur une infrastructure opérée par Mélodium peuvent utiliser des clusters partagés ou dédiés à la place, voir [Intégration Kubernetes](/fr/docs/how-it-works/kubernetes#clusters-auto-gérés-vs-clusters-opérés-par-mélodium) pour la distinction.

La délimitation des runners/secrets par équipe et l'intégration IAM avec des fournisseurs d'identité externes figurent sur la [feuille de route](/fr/docs/roadmap#organisation-et-sécurité).

### Sécurité au niveau du cœur

Cadence.CI s'appuie sur les propriétés d'exécution de Mélodium pour des garanties de sécurité intégrées directement à la couche d'exécution :

- **Validation fail-fast** : l'ensemble du programme est validé au démarrage. Les configurations invalides ou non sécurisées sont stoppées immédiatement, avant qu'un runner soit créé ou qu'une ressource de calcul soit provisionnée.
- **Gestion des secrets en mémoire** : les valeurs sensibles sont identifiées en mémoire, maintenues isolées au traitement qui les utilise, et supprimées en toute sécurité après utilisation.

### Langage de programmation

> Le langage Mélodium pour définir les pipelines CI/CD : syntaxe, concepts, et différences avec le YAML CI classique.

Source: https://cadence.ci/fr/docs/how-it-works/programming-language
Preferred fetch: https://cadence.ci/fr/docs/how-it-works/programming-language.md

Les pipelines CI/CD sont fondamentalement des programmes, ils orchestrent des tâches, acheminent des données, réagissent à des événements et coordonnent du travail sur plusieurs machines. Pourtant, la plupart des outils de pipeline reposent sur des approches qui n'ont jamais été conçues pour cela.

## Pourquoi les approches existantes sont insuffisantes

### Configuration YAML

Des outils comme GitHub Actions, GitLab CI et CircleCI représentent les pipelines sous forme de fichiers YAML décrivant des séquences de commandes shell. Cela fonctionne pour les cas simples, mais atteint rapidement des limites structurelles :

- **Pas de transmission native de données** : les données entre jobs doivent être sérialisées sur disque, téléversées comme artefacts, puis téléchargées et désérialisées dans le job suivant. Il n'existe pas de concept de flux.
- **Parallélisme grossier** : les jobs peuvent s'exécuter en parallèle, mais la coordination au sein d'un job reste séquentielle. La concurrence fine nécessite des contournements.
- **Expressivité limitée** : les conditions sont maladroites, les boucles sont limitées ou absentes, et tout ce qui dépasse une séquence linéaire requiert des scripts externes.
- **Observabilité plate** : une exécution en échec produit des logs à plat. Il n'existe pas de trace structurée indiquant quel traitement a reçu quelle entrée, diagnostiquer une erreur revient à parcourir des sorties plutôt qu'à inspecter un état.

### Scripts impératifs

Groovy (Jenkinsfile), Python et les langages de script similaires offrent plus de flexibilité, mais introduisent leurs propres problèmes lorsqu'ils sont utilisés pour l'orchestration de pipelines :

- **Modèle mental séquentiel** : les scripts s'exécutent ligne par ligne. Exprimer une exécution concurrente, un fan-out ou un comportement réactif nécessite une gestion explicite des threads ou des constructions asynchrones non prévues pour cet usage.
- **Pas de distribution native** : distribuer du travail sur plusieurs machines nécessite d'écrire du code de coordination, appels SSH, files de tâches ou orchestration personnalisée. L'auteur du pipeline gère la distribution, pas le langage.
- **Gestion manuelle des flux** : transmettre un flux d'octets ou d'événements entre machines implique d'écrire manuellement le buffering, le découpage et la gestion des erreurs.
- **Topologie opaque** : un script n'a pas de structure intrinsèque qu'un outil peut inspecter. Déboguer revient à lire des logs d'exécution plutôt qu'à comprendre la forme du programme.

## Pourquoi Mélodium est adapté

Mélodium a été conçu spécifiquement pour les programmes que les pipelines CI/CD sont réellement : **distribués**, **orientés flux**, **réactifs** et **inspectables**.

```mermaid
graph TD
  subgraph yaml["YAML / Scripts impératifs"]
    y1[Étape A] -->|upload d'artefact| y2[Étape B]
    y2 -->|upload d'artefact| y3[Étape C]
    y3 -->|upload d'artefact| y4[Étape D]
  end

  subgraph mel["Pipelines Mélodium"]
    m1[Traitement A] -->|flux typé| m2[Traitement B]
    m1 -->|flux typé| m3[Traitement C]
    m2 -->|flux typé| m4[Traitement D]
    m3 -->|flux typé| m4
  end
```

*Les pipelines YAML transmettent les données via des uploads d'artefacts séquentiels. Les traitements Mélodium se connectent via des flux typés et s'exécutent en parallèle dès que leurs entrées sont disponibles.*

### Les flux comme entités de premier ordre

Les données circulent entre les traitements sous forme de flux typés, sans aller-retours de sérialisation entre les étapes. Fichiers, octets et valeurs structurées se déplacent directement d'un traitement au suivant, même à travers les frontières machine. Le système de types garantit qu'un `Stream<byte>` ne peut pas être accidentellement connecté à une entrée attendant un `Block<string>`, détectant les erreurs de connexion avant toute exécution.

### Distribution native

Un programme Mélodium déclare *ce qui s'exécute où*. Le runtime prend en charge la création de processus sur des machines distantes, l'établissement des connexions entre eux et la coordination de l'exécution. L'auteur du pipeline écrit de la logique ; Mélodium gère la distribution. Il n'y a pas de code de coordination, pas d'infrastructure SSH, pas de file de tâches à gérer.

```mermaid
flowchart LR
  subgraph "Local / Processus initial"
    entry[Traitement d'entrée]
  end

  subgraph "Runner A (Cloud)"
    t1[Traitement B]
    t2[Traitement C]
  end

  subgraph "Runner B (On-Prem)"
    t3[Traitement D]
  end

  entry -->|flux typé| t1
  entry -->|flux typé| t3
  t1 -->|flux typé| t2
  t2 -->|flux typé| t3
```

*Le même programme Mélodium peut distribuer des traitements sur des machines d'infrastructures différentes. La topologie de connexion est déclarée dans le programme, le runtime gère le reste.*

### Exécution réactive

Les traitements s'exécutent quand leurs entrées arrivent, et non selon un calendrier prédéfini. L'exécution parallèle, le fan-out et la synchronisation s'expriment comme des connexions dans le graphe de programme. Il n'est pas nécessaire de marquer explicitement des jobs comme `parallel: true` ou de gérer des conditions d'attente en code impératif, la concurrence est une conséquence naturelle de la topologie du flux de données.

### Validation statique

L'ensemble du programme, ses types, connexions et configuration, est validé avant toute exécution. Les incohérences de types, les connexions manquantes et les configurations invalides sont détectées au démarrage, pas découvertes à mi-chemin d'un build de 20 minutes quand un job en aval échoue à recevoir son entrée attendue.

### Débogage en profondeur

Parce que le modèle d'exécution possède une topologie bien définie de traitements connectés par des flux typés, Cadence.CI peut observer les entrées, sorties et états intermédiaires à chaque nœud du graphe. C'est ce qui rend possible le [débogage au niveau des traitements](/fr/docs/how-it-works/general#monitoring-et-débogage), quelque chose de structurellement impossible dans les pipelines basés sur des scripts, où il n'existe pas de concept de « données circulant entre l'étape A et l'étape B ».

## Récapitulatif

| | Config YAML | Script impératif | Mélodium |
|---|---|---|---|
| Transmission de données | Upload d'artefacts | Sérialisation manuelle | Flux typés |
| Parallélisme | Au niveau des jobs | Async explicite | Piloté par la topologie |
| Distribution | Non native | Coordination manuelle | Intégrée au langage |
| Validation | À l'exécution | À l'exécution | Au démarrage (statique) |
| Débogage | Logs à plat | Logs à plat | Traçage E/S par traitement |

### Intégration cloud

> Intégration avec les fournisseurs cloud pour que les runners s'exécutent dans votre propre projet cloud.

Source: https://cadence.ci/fr/docs/how-it-works/clouds
Preferred fetch: https://cadence.ci/fr/docs/how-it-works/clouds.md

**Cadence.CI** s'intègre directement avec les fournisseurs de cloud afin que les runners Mélodium soient déployés et s'exécutent entièrement dans votre propre projet cloud, gardant vos données au sein d'une infrastructure que vous contrôlez.

## Fonctionnement

Lorsque vous connectez un compte fournisseur de cloud, Cadence.CI utilise les identifiants d'accès que vous fournissez pour provisionner et gérer des instances de runners en votre nom. Les runners restent dans le réseau de votre projet et communiquent directement entre eux, tandis que Cadence.CI gère l'orchestration depuis l'extérieur.

```mermaid
sequenceDiagram
  participant Pipeline as Pipeline Mélodium
  participant Cadence as Cadence.CI
  participant Cloud as Votre projet cloud

  Pipeline->>Cadence: Demande de création de runner
  Cadence->>Cloud: Provisionnement VM / instance (via vos identifiants)
  Cloud-->>Cadence: Instance prête
  Cadence-->>Pipeline: Runner disponible
  Pipeline->>Cloud: Distribution du travail directement au runner
  Cloud-->>Pipeline: Logs + résultats
  Pipeline->>Cadence: Tâche terminée, supprimer le runner
  Cadence->>Cloud: Destruction de l'instance
```

## Étapes de configuration

1. **Fournir les identifiants d'accès** : donnez à Cadence.CI les clés d'accès ou le compte de service nécessaires pour provisionner des ressources de calcul dans votre projet cloud. Les permissions requises varient selon le fournisseur et sont documentées sur la page de configuration de chacun.
2. **Configuration de l'infrastructure** : Cadence.CI configure automatiquement les paramètres réseau et d'instance requis dans votre projet.
3. **Déploiement des runners** : lors de l'exécution d'un pipeline, les runners Mélodium sont déployés directement dans votre environnement cloud.
4. **Exécution directe** : les étapes du pipeline s'exécutent dans votre infrastructure, avec un accès direct aux ressources co-localisées via votre propre réseau.

## Avantages

- **Performances** : l'exécution directe dans votre infrastructure élimine les sauts réseau inutiles entre les étapes du pipeline et vos ressources.
- **Sécurité** : les données restent dans votre environnement cloud tout au long de l'exécution.
- **Efficacité économique** : les runners utilisent directement votre quota et votre facturation existants.
- **Conformité** : la résidence des données et les exigences réglementaires sont respectées car le calcul reste dans votre région et projet désignés.

## Fournisseurs de cloud pris en charge

Cadence.CI prend actuellement en charge l'intégration avec les fournisseurs de cloud suivants :

<div style="display: grid; grid-template-columns: repeat(auto-fill, minmax(150px, 1fr)); gap: 20px; margin: 20px 0;">
  <div style="text-align: center;">
    <div style="min-height: 64px; max-width: 64px; margin: 0 auto; display: flex; align-items: center; justify-content: center;">
      <img src="/img/logos/scaleway-logo.svg" alt="Scaleway" style="max-width: 64px; height: auto; min-height: 64px;">
    </div>
    <p><strong>Scaleway</strong></p>
  </div>
  <div style="text-align: center;">
    <div style="min-height: 64px; max-width: 64px; margin: 0 auto; display: flex; align-items: center; justify-content: center;">
      <img src="/img/logos/aws-logo.svg" alt="AWS" style="max-width: 64px; height: auto; min-height: 64px;">
    </div>
    <p><strong>AWS</strong></p>
  </div>
</div>

Les instructions de configuration spécifiques à chaque fournisseur, les permissions requises et les types d'instances pris en charge sont documentés sur la page de chaque fournisseur. D'autres fournisseurs figurent sur la [feuille de route](/fr/docs/roadmap#fournisseurs-de-cloud).

### Intégration Kubernetes

> Exécution des runners Mélodium comme pods dans votre propre cluster Kubernetes.

Source: https://cadence.ci/fr/docs/how-it-works/kubernetes
Preferred fetch: https://cadence.ci/fr/docs/how-it-works/kubernetes.md

**Cadence.CI** s'intègre avec Kubernetes afin que les runners Mélodium soient déployés en tant que pods directement dans votre cluster. L'exécution des pipelines reste dans votre infrastructure, en utilisant votre réseau, stockage et politiques de calcul existants.

## Fonctionnement

Un contrôleur Kubernetes léger est déployé dans votre cluster. Il surveille les demandes de provisionnement de runners émises par Cadence.CI et crée les pods correspondants. À la fin d'une tâche, il supprime ces pods. Toutes les interactions avec votre cluster passent exclusivement par le contrôleur.

```mermaid
flowchart LR
  cadence["Cadence.CI"]
  controller["Contrôleur Kubernetes\n(dans votre cluster)"]
  pods["Pods runners"]

  cadence -->|demande de runner| controller
  controller -->|création / suppression de pods| pods
  pods -.->|logs + télémétrie| cadence
```

## Étapes de configuration

1. **Déployer le contrôleur** : installez le contrôleur Kubernetes de Cadence.CI dans votre cluster. Il s'enregistre auprès de Cadence.CI et gère la communication entre Cadence.CI et le serveur d'API de votre cluster.
2. **Configurer l'accès au cluster** : le contrôleur utilise un compte de service limité aux seules permissions nécessaires pour créer et supprimer des pods runners et leurs objets `ServiceAccount`/`Role`/`RoleBinding` associés.
3. **Déploiement des runners** : lors de l'exécution d'un pipeline, les runners Mélodium sont créés en tant que pods dans votre cluster, en utilisant le namespace et les quotas de ressources que vous configurez.
4. **Exécution directe** : les étapes du pipeline s'exécutent dans votre cluster, avec un accès direct aux services internes et au stockage.

## Avantages

- **Sécurité** : les données restent dans votre environnement Kubernetes tout au long de l'exécution.
- **Efficacité économique** : les runners utilisent directement la capacité de votre cluster existant.
- **Conformité** : le calcul reste dans votre cluster désigné, respectant les exigences de résidence des données.
- **Scalabilité** : le scheduler Kubernetes gère automatiquement le placement des pods et l'allocation des ressources.
- **Self-healing** : si un pod runner est évincé ou plante, Kubernetes le replanifie et Cadence.CI relance le travail affecté.

## Clusters auto-gérés vs. clusters opérés par Mélodium

Les clusters enregistrés auprès de Cadence.CI relèvent de l'un des trois modes de service suivants :

- **Auto-géré (self-managed)** : un cluster que vous possédez et exploitez, enregistré avec votre propre jeton de cluster. C'est le modèle décrit ci-dessus, tout s'exécute sur votre infrastructure.
- **Partagé (shared)** : un cluster exploité par Mélodium, disponible pour les organisations sur les offres éligibles. Les runners s'exécutent toujours comme des pods isolés avec des comptes de service limités par tâche, sur une infrastructure Mélodium partagée entre organisations.
- **Dédié (dedicated)** : un cluster exploité par Mélodium et réservé à une seule organisation.

L'architecture au niveau des pods, contrôleur, comptes de service limités, accès au cluster restreint au contrôleur, est identique dans les trois modes. Les clusters auto-gérés s'exécutent entièrement sur une infrastructure que vous contrôlez ; les clusters partagés et dédiés s'exécutent sur une infrastructure exploitée par Mélodium en votre nom.

## Configurations disponibles

Cadence.CI peut fonctionner sur toute distribution Kubernetes standard. Des configurations de cluster préconstruites sont disponibles pour des fournisseurs spécifiques. Consultez les pages de cette section pour les guides de configuration par fournisseur.

## Démarrage (français)

- [Construire un pipeline CI/CD depuis zéro](https://cadence.ci/fr/docs/from-scratch/build-a-ci.md): Guide pas à pas pour construire un pipeline qui clone un dépôt, compile un binaire et renvoie le résultat.
- [Template CI/CD](https://cadence.ci/fr/docs/from-template/cicd.md): Partir du template CI/CD officiel pour obtenir rapidement un pipeline fonctionnel.
- [Déployer sur GitHub Actions](https://cadence.ci/fr/docs/from-template/on-github.md): Intégrer les pipelines Cadence.CI avec GitHub Actions comme déclencheur.
- [Déployer sur GitLab CI](https://cadence.ci/fr/docs/from-template/on-gitlab.md): Intégrer les pipelines Cadence.CI avec GitLab CI comme déclencheur.
- [Implémentation avancée](https://cadence.ci/fr/docs/from-template/advanced-implementation.md): Patterns avancés : traitements détaillés, composants réutilisables et composition de pipelines complexes.

### Construire un pipeline CI/CD depuis zéro

> Guide pas à pas pour construire un pipeline qui clone un dépôt, compile un binaire et renvoie le résultat.

Source: https://cadence.ci/fr/docs/from-scratch/build-a-ci
Preferred fetch: https://cadence.ci/fr/docs/from-scratch/build-a-ci.md

Ce guide explique comment construire un pipeline CI/CD de zéro en utilisant Cadence.CI et le langage Mélodium. À la fin, vous aurez un pipeline fonctionnel qui clone un dépôt, compile un binaire et streame le résultat vers votre machine locale.

> [!NOTE]
>
> Vous avez besoin de [Mélodium](https://melodium.tech/en/download) version `0.10.0` ou supérieure installée.
> Pour une introduction plus approfondie au langage Mélodium, consultez le [Livre du Langage Mélodium](https://doc.melodium.tech/book/en/).

## Créer le projet

Commencez par créer la structure d'un nouveau programme Mélodium :

```sh
melodium new my_cicd
```

Ouvrez ensuite `my_cicd/Compo.toml` et ajoutez les dépendances suivantes :

```toml
[dependencies]
std = "0.10.0"
cicd = "0.10.0"
fs = "0.10.0"
process = "0.10.0"
work = "0.10.0"
```

Ces packages fournissent la bibliothèque standard, les primitives de runner CI/CD, l'accès au système de fichiers, la gestion des processus et les définitions de ressources.

## Définir le traitement

Un **traitement** en Mélodium est une unité de travail nommée avec des entrées, des sorties et des dépendances typées. Ouvrez `my_cicd/lib-root.mel` et déclarez le traitement `buildSoftware` :

```rust
use cicd/runners::CicdDispatchEngine
use cicd/runners::CicdRunnerEngine

treatment buildSoftware[cicd: CicdDispatchEngine]()
  input trigger:   Block<void>
  output finished: Block<void>
  output binary:   Stream<byte>
  model runner: CicdRunnerEngine()
{
    
}
```

Décomposition de la signature :

- `[cicd: CicdDispatchEngine]`, le modèle de dispatch qui gère le provisionnement des runners ([docs](https://doc.melodium.tech/latest/en/cicd/runners/CicdDispatchEngine.html)).
- `input trigger: Block<void>`, un signal qui déclenche le build.
- `output finished: Block<void>`, un signal émis quand le build se termine.
- `output binary: Stream<byte>`, un flux d'octets typé transportant le binaire compilé.
- `model runner: CicdRunnerEngine()`, le modèle de runner que ce traitement utilisera ([docs](https://doc.melodium.tech/latest/en/cicd/runners/CicdRunnerEngine.html)).

<div className="place-content-center p-3 flex">
<img src="/img/scratch_buildSoftware_outside_light.png" className="dark:hidden rounded shadow"/>
<img src="/img/scratch_buildSoftware_outside_dark.png" className="hidden dark:block rounded shadow"/>
</div>

## Définir les étapes

Dans le corps du traitement, déclarez trois étapes qui s'exécuteront séquentiellement sur le runner : l'installation des outils, le clonage du dépôt et la compilation du binaire.

```rust
use cicd/steps::stepOn
use process/command::|raw_commands
/* … */

install: stepOn[runner=runner](
    name="install",
    executor_name="ubuntu",
    commands=|raw_commands([
        "apt-get update",
        "apt-get install -y gcc"
    ])
)

clone: stepOn[runner=runner](
    name="clone",
    executor_name="ubuntu",
    commands=|raw_commands([
        "git clone https://github.com/niwasawa/c-hello-world.git"
    ])
)

build: stepOn[runner=runner](
    name="build",
    executor_name="ubuntu",
    commands=|raw_commands([
        "gcc c-hello-world/hello.c",
        "mv a.out /mnt/data/executable"
    ]),
    out_filesystem="data",
    out_file="executable"
)
```

Les trois étapes s'exécutent sur l'exécuteur nommé `"ubuntu"` du `runner`. L'étape `build` streame également le fichier compilé via le paramètre `out_file`. Consultez la [documentation de `stepOn`](https://doc.melodium.tech/latest/en/cicd/steps/stepOn.html) pour la référence complète.

<div className="place-content-center p-3 flex">
<img src="/img/scratch_makestep_light.png" className="dark:hidden rounded shadow"/>
<img src="/img/scratch_makestep_dark.png" className="hidden dark:block rounded shadow"/>
</div>

## Connecter les étapes

Les étapes sont connectées en déclarant des flux de données entre leurs entrées et sorties. Les étapes `install` et `clone` peuvent s'exécuter en parallèle ; `build` attend que les deux soient terminées avant de démarrer.

```rust
use std/flow::waitBlock
/* … */

awaitPrepare: waitBlock<void>()

install.success -> awaitPrepare.a
clone.success ---> awaitPrepare.b

awaitPrepare.awaited -> build.trigger,finished -> Self.finished
                        build.data -------------> Self.binary
```

`waitBlock` est une primitive de synchronisation qui émet `awaited` seulement après que `a` et `b` ont tous les deux reçu une valeur. Une fois `build` terminé, `finished` et `binary` sont transmis aux propres sorties du traitement.

<div className="place-content-center p-3 flex">
<img src="/img/scratch_assemble_light.png" className="dark:hidden rounded shadow"/>
<img src="/img/scratch_assemble_dark.png" className="hidden dark:block rounded shadow"/>
</div>

## Provisionner le runner

Les étapes ci-dessus s'exécutent sur un runner, mais le runner lui-même doit être démarré et arrêté dans le traitement. Ajoutez les appels `setupRunner` et `stopRunner` et connectez-les au cycle de vie des étapes :

```rust
use cicd/runners::setupRunner
use cicd/runners::stopRunner
use work/resources/arch::|amd64
use work/resources::|container
use work/resources::|mount
use work/resources::|volume
/* … */

setupRunner[dispatcher=cicd, runner=runner](
  cpu=200,
  memory=100,
  storage=100,
  name="builder",
  volumes=[|volume("data", 30)],
  containers=[|container("ubuntu", 1000, 1000, 1000, |amd64(), [|mount("data", "/mnt/data")], "ubuntu:latest", _)]
)
stopRunner[runner=runner]()

Self.trigger -> setupRunner.trigger,ready -> install.trigger
                setupRunner.ready ---------> clone.trigger
                                             build.finished -> stopRunner.trigger
```

Le runner est démarré quand le traitement est déclenché, `install` et `clone` démarrent dès qu'il est prêt, et `stopRunner` est appelé après que `build` se termine. Le runner n'est jamais inactif plus longtemps que nécessaire.

<div className="place-content-center p-3 flex">
<img src="/img/scratch_setuprunner_light.png" className="dark:hidden rounded shadow"/>
<img src="/img/scratch_setuprunner_dark.png" className="hidden dark:block rounded shadow"/>
</div>

## Traitement complet

En assemblant tout :

```rust
use cicd/runners::CicdDispatchEngine
use cicd/runners::CicdRunnerEngine
use cicd/runners::setupRunner
use cicd/runners::stopRunner
use cicd/steps::stepOn
use process/command::|raw_commands
use std/flow::waitBlock
use work/resources/arch::|amd64
use work/resources::|container
use work/resources::|mount
use work/resources::|volume

treatment buildSoftware[cicd: CicdDispatchEngine]()
  input trigger:   Block<void>
  output finished: Block<void>
  output binary:   Stream<byte>
  model runner: CicdRunnerEngine()
{
    setupRunner[dispatcher=cicd, runner=runner](
        cpu=200,
        memory=100,
        storage=100,
        name="builder",
        volumes=[|volume("data", 30)],
        containers=[|container("ubuntu", 1000, 1000, 1000, |amd64(), [|mount("data", "/mnt/data")], "ubuntu:latest", _)]
    )
    stopRunner[runner=runner]()

    Self.trigger -> setupRunner.trigger,ready -> install.trigger
                    setupRunner.ready ---------> clone.trigger
                                                 build.finished -> stopRunner.trigger

    install: stepOn[runner=runner](
        name="install",
        executor_name="ubuntu",
        commands=|raw_commands([
            "apt-get update",
            "apt-get install -y gcc"
            ])
    )
    clone: stepOn[runner=runner](
        name="clone",
        executor_name="ubuntu",
        commands=|raw_commands([
            "git clone https://github.com/niwasawa/c-hello-world.git"
        ])
    )
    build: stepOn[runner=runner](
        name="build",
        executor_name="ubuntu",
        commands=|raw_commands([
            "gcc c-hello-world/hello.c",
            "mv a.out /mnt/data/executable"
        ]),
        out_filesystem="data",
        out_file="executable"
    )

    awaitPrepare: waitBlock<void>()

    install.success -> awaitPrepare.a
    clone.success ---> awaitPrepare.b

    awaitPrepare.awaited -> build.trigger,finished -> Self.finished
                            build.data -------------> Self.binary
}
```

## Créer le point d'entrée

Un traitement ne peut pas être exécuté directement ; il nécessite un point d'entrée qui le connecte au monde extérieur. Ajoutez un traitement `runBuild` dans `my_cicd/lib-root.mel` :

```rust
use fs/local::writeLocal
use std/engine/util::startup

treatment runBuild(var output_file: string = "./executable")
  model cicd: CicdDispatchEngine(location="compose", api_token="")
{
    startup()

    buildSoftware[cicd=cicd]()
    writeLocal(path=output_file)

    startup.trigger -> buildSoftware.trigger,binary -> writeLocal.data
}
```

Déclarez-le ensuite comme point d'entrée du programme dans `my_cicd/Compo.toml` :

```toml
[entrypoints]
main = "my_cicd::runBuild"
```

## Exécuter

```sh
melodium my_cicd/Compo.toml
```

Un fichier nommé `executable` apparaîtra dans le répertoire courant une fois le pipeline terminé.

> [!NOTE]
>
> Le `CicdDispatchEngine` est configuré avec `location="compose"` ici, ce qui utilise Podman Compose ou Docker Compose pour provisionner les runners localement. Pour une utilisation en production avec Cadence.CI, définissez `location` sur votre cluster configuré et fournissez le `api_token` approprié. Voir la [documentation de `CicdDispatchEngine`](https://doc.melodium.tech/latest/en/cicd/runners/CicdDispatchEngine.html).

## Programme complet

Téléchargez le [programme complet](/downloads/my_cicd.zip) pour référence.

### Template CI/CD

> Partir du template CI/CD officiel pour obtenir rapidement un pipeline fonctionnel.

Source: https://cadence.ci/fr/docs/from-template/cicd
Preferred fetch: https://cadence.ci/fr/docs/from-template/cicd.md

Cadence.CI s'appuie sur la technologie Mélodium pour fournir un service puissant et efficace. Ce tutoriel explique comment créer un CI/CD détaillé avec Mélodium.

Pour le CI/CD au sein de services existants, les intégrations GitHub et GitLab sont expliquées dans les sections suivantes.

> [!NOTE]
>
> Vous avez besoin de [Mélodium](https://melodium.tech/en/download) version `0.10.0` ou supérieure installée.

## Créer un projet CI/CD Mélodium

À la racine du dépôt git, exécutez la commande `melodium new --template cicd --path .melodium-ci cicd`.
Un dossier `.melodium-ci/` est alors créé, contenant le code de base pour un CI fonctionnel.

Ce dossier contient trois fichiers :
- `Compo.toml`
- `lib-root.mel`
- `advanced.mel`

Le fichier `Compo.toml` contient la configuration du programme CI/CD.
`lib-root.mel` contient le programme CI/CD lui-même, et `advanced.mel` le même programme mais implémenté de façon avancée (ignoré dans cette page, voir [Implémentation Avancée](advanced-implementation)).

Dans `lib-root.mel` se trouve le traitement `main`, désigné comme point d'entrée principal par la configuration de base.
Il n'est pas obligatoire pour un programme d'avoir un tel point d'entrée principal ; différents points d'entrée peuvent être utilisés pour différents modes de fonctionnement.

Le traitement `main` contient tous les éléments de base pour faire fonctionner le CI/CD :
- quelques paramètres pour gérer l'échange de données en dehors du processus CI/CD,
- un [`CicdDispatchEngine`](https://doc.melodium.tech/latest/en/cicd/runners/index.html) pour gérer la distribution du travail entre les différents services et runners,
- des traitements tels que [`startup`](https://doc.melodium.tech/latest/en/std/engine/util/startup.html), `build` et `test`.

Le traitement [`startup`](https://doc.melodium.tech/latest/en/std/engine/util/startup.html) est fourni par la bibliothèque standard Mélodium pour déclencher n'importe quoi dès le début du programme.

<img src="/img/main_simple_light.png" className="dark:hidden rounded shadow"/>
<img src="/img/main_simple_dark.png" className="hidden dark:block rounded shadow"/>


## Implémentation CI/CD

Les traitements `build` et `test` sont basés sur [`simpleStep`](https://doc.melodium.tech/latest/en/cicd/naive/simpleStep.html) et [`simpleStepWithInput`](https://doc.melodium.tech/latest/en/cicd/naive/simpleStepWithInput.html).

Ils prennent tous les deux le modèle [`CicdDispatchEngine`](https://doc.melodium.tech/latest/en/cicd/runners/index.html) et un signal d'entrée `trigger`.

```rust
build: simpleStep[cicd=cicd](
    name="build",
    image="ubuntu:noble",
    commands=|raw_commands([
    "apt-get update",
    "apt-get install -y git",
    "git config --global url.https://.insteadOf  git://",
    |format("git clone --branch {repository_clone_ref} --depth 1 {repository_clone_url} project",
        |map([
            |entry("repository_clone_ref", repository_clone_ref),
            |entry("repository_clone_url", repository_clone_url)
        ])
    ),
    "sh -c \"cd project/ ; ls -l --almost-all | tee files-list.txt\"",
    "mv project/files-list.txt /mnt/data/"
    ]),
    out_file="files-list.txt"
)
```

```rust
test: simpleStepWithInput[cicd=cicd](
    name="test",
    image="alpine",
    in_file="list.txt",
    commands=[
        |command("test", ["-s", "/mnt/data/list.txt"]),
        |command("cat", ["/mnt/data/list.txt"])
    ]
)
```

Ils prennent tous les deux quelques paramètres :
- `name`, une chaîne nommant l'étape elle-même, utilisée dans les logs et les rapports ;
- `image`, l'image de conteneur à utiliser ;
- `pull_secret`, le secret (optionnel) à utiliser pour récupérer l'image de conteneur ;
- `commands`, la liste des commandes à exécuter ;
- `out_file`, le fichier (optionnel) à streamer comme sortie `data`.

Quelques paramètres sont disponibles pour configurer plus précisément une étape :
- `memory`, mémoire (en mébioctets) dédiée au conteneur ;
- `cpu`, quantité de CPUs (en millicores) ;
- `storage`, espace disque (en mébioctets) disponible ;
- `arch`, désignant l'architecture matérielle sur laquelle l'étape doit s'exécuter (ARM64 par défaut).

> Actuellement les architectures AMD64/x86_64 [`|amd64()`](https://doc.melodium.tech/latest/en/work/resources/arch/|amd64.html) et ARM64/aarch64 [`|arm64()`](https://doc.melodium.tech/latest/en/work/resources/arch/|arm64.html) sont supportées.

## Traitement des commandes

Le paramètre `commands` est une liste de commandes exécutées dans le conteneur.

Les commandes peuvent être spécifiées de plusieurs façons :
- fonction [`|command()`](https://doc.melodium.tech/latest/en/process/command/|command.html), pour une commande détaillée avec liste d'arguments ;
- fonction [`|raw_command()`](https://doc.melodium.tech/latest/en/process/command/|raw_command.html), pour une commande en chaîne brute ;
- fonction [`|raw_commands()`](https://doc.melodium.tech/latest/en/process/command/|raw_commands.html), pour une liste complète de commandes en chaîne.

## Déclencher et connecter les étapes

Les traitements [`simpleStep`](https://doc.melodium.tech/latest/en/cicd/naive/simpleStep.html) et [`simpleStepWithInput`](https://doc.melodium.tech/latest/en/cicd/naive/simpleStepWithInput.html) fournissent tous les deux des entrées et des sorties :
- entrée `trigger`, pour instancier le conteneur et démarrer le traitement ;
- sortie `started`, pour signaler quand les commandes commencent à s'exécuter ;
- sortie `completed`, pour signaler la complétion réussie de l'étape ;
- sortie `failed`, pour signaler l'échec de l'étape ;
- sortie `finished`, pour signaler que l'étape est terminée, qu'elle ait réussi ou non ;
- sortie `data`, streamant les données du fichier donné dans `out_file`.

De plus, `simpleStepWithInput` fournit une entrée `data` pour écrire le fichier `in_file` dans le conteneur avant d'exécuter les commandes.

```rust
startup.trigger -> build.trigger,data -> test.data
startup.trigger -----------------------> test.trigger
```

<img src="/img/main_example_light.png" className="dark:hidden rounded shadow"/>
<img src="/img/main_example_dark.png" className="hidden dark:block rounded shadow"/>

## Dispatch et distribution

Mélodium distribue le travail parmi les workers situés sur différents conteneurs et machines, selon les exigences données.
Le même programme CI/CD unique peut s'exécuter sur plusieurs processus et machines et permet une synchronisation et une planification précises entre des systèmes hétérogènes.

Un [`CicdDispatchEngine`](https://doc.melodium.tech/latest/en/cicd/runners/CicdDispatchEngine.html) peut être configuré pour distribuer le travail via l'API cloud ou localement en utilisant la composition de conteneurs, indépendamment de l'endroit où le processus initial s'exécute.

Le paramètre `location` spécifie la méthode de dispatch à utiliser, avec les valeurs `"api"` (par défaut) ou `"compose"`, envoyant respectivement les demandes de runner au dispatch à l'API ou les lançant via Podman Compose ou Docker Compose. Dans le cas de la composition de conteneurs, la satisfaction des exigences dépend des capacités de la machine, notamment l'architecture et la mémoire totale disponible.

> [!NOTE]
>
> La distribution `"compose"` peut être utilisée dans des services CI/CD comme GitHub Actions et GitLab CI pour tirer pleinement parti des runners fournis sans dépendre de runners externes supplémentaires.

## Exécuter le CI/CD localement avec distribution distante

Pour exécuter le programme CI/CD, invoquez Mélodium avec les paramètres du programme :
```sh
melodium .melodium-ci/Compo.toml --api_token <VOTRE_TOKEN_RUN_API> --output_directory /votre/répertoire/de/sortie --repository_clone_url <URL_CLONE_COMPLETE>.git --repository_clone_ref <BRANCHE_OU_TAG>
```

Où `VOTRE_TOKEN_RUN_API` est un token Run de Cadence.CI. Cela exécute le "moteur principal" du CI/CD depuis l'ordinateur local et distribue le travail sur des workers distants.

Tous les logs CI/CD sont affichés dans le terminal, et les données sont écrites dans `/votre/répertoire/de/sortie`.

## Exécuter le CI/CD localement avec distribution locale

Si Podman Compose ou Docker Compose est installé localement, il est possible de lancer le CI/CD avec distribution locale :
```sh
melodium .melodium-ci/Compo.toml --work_location compose --api_token <VOTRE_TOKEN_RUN_API> --output_directory /votre/répertoire/de/sortie --repository_clone_url <URL_CLONE_COMPLETE>.git --repository_clone_ref <BRANCHE_OU_TAG>
```

Notez que le CI/CD est alors contraint aux capacités de la machine hôte, notamment en termes de mémoire et d'architecture.

> [!NOTE]
>
> Le service Container Runtime doit être en cours d'exécution. C'est le cas par défaut avec Docker. Avec Podman, le service `podman` doit être lancé (ex. : `podman system service --time 0 unix:///run/user/1000/podman/podman.sock`).

## Exécuter le CI/CD sur un service

Le CI/CD est exécutable sur tout service capable de faire tourner Mélodium. Les plus courants sont GitHub et GitLab, pour lesquels des procédures détaillées sont données dans les sections suivantes.

### Implémentation avancée

> Patterns avancés : traitements détaillés, composants réutilisables et composition de pipelines complexes.

Source: https://cadence.ci/fr/docs/from-template/advanced-implementation
Preferred fetch: https://cadence.ci/fr/docs/from-template/advanced-implementation.md

Voici une explication de l'implémentation avancée du CI/CD, utilisant des traitements et des outils plus détaillés.
`main` fonctionne de la même façon que dans la version racine ; les traitements `build` et `test` proviennent du fichier `advanced.mel` et contiennent l'implémentation CI/CD.

## Implémentation CI/CD

Les traitements `build` et `test` sont implémentés de la même façon : ils nécessitent de configurer un runner sur lequel les étapes sont distribuées.
Leur implémentation de base est donnée comme exemple fonctionnel simple.

Ils prennent tous les deux le modèle [`CicdDispatchEngine`](https://doc.melodium.tech/latest/en/cicd/runners/index.html) et un signal d'entrée `trigger`. [`CicdDispatchEngine`](https://doc.melodium.tech/latest/en/cicd/runners/index.html) et l'entrée `trigger` sont utilisés pour demander un nouveau runner distribué [`CicdRunnerEngine`](https://doc.melodium.tech/latest/en/cicd/runners/index.html) via [`setupRunner`](https://doc.melodium.tech/latest/en/cicd/runners/setupRunner.html) dès que c'est utile.

```rust
treatment build[cicd: CicdDispatchEngine](repository_clone_url: string, repository_clone_ref: string)
  model runner: CicdRunnerEngine()
  input trigger: Block<void>
  output data:   Stream<byte>
{
    setupRunner[
        dispatcher=cicd,
        runner=runner
    ](
        name="build",
        cpu=100, // mCPU
        memory=500, // MB
        storage=1000, // MB
        volumes=[
            // Volumes mis à disposition
            |volume("build-result", 30 /* MB */)
        ],
        containers=[
            |container("ubuntu", // Nom du conteneur
                1000, // mCPU
                200, // MB
                8000, // MB
                |amd64(),
                [ // Points de montage
                    |mount("build-result", "/mounted/result")
                ],
                "ubuntu:noble", // Nom de l'image
                _)
        ]
    )
    gitClone: stepOn[runner=runner](
        executor_name="ubuntu", // Utilise le conteneur "ubuntu"
        environment=|wrap<Environment>(|environment(|map([/* Pas de variables d'env */]), "/root", false, false)),
        commands=[
            |command("apt-get", ["update"]),
            |command("apt-get", ["install", "-y", "git"]),
            |command("git", ["config", "--global", "url.https://.insteadOf", "git://"]),
            |command("git", ["clone", "--branch", repository_clone_ref, "--depth", "1", repository_clone_url, "project"])
        ]
    )
    makeList: stepOn[runner=runner](
        executor_name="ubuntu", // Utilise le conteneur "ubuntu"
        environment=|wrap<Environment>(|environment(|map([]), "/root/project", false, false)),
        commands=|raw_commands([
            "sh -c \"ls -l --almost-all | tee files-list.txt\"",
            "mv files-list.txt /mounted/result/"
        ]),
        out_filesystem="build-result",
        out_file="files-list.txt"
    )
    stopRunner[runner=runner]()

    Self.trigger -> setupRunner.trigger,ready -> gitClone.trigger,completed -> makeList.trigger,finished -> stopRunner.trigger
                                                                               makeList.data -------------> Self.data
}
```

<img src="/img/main_advanced_light.png" className="dark:hidden rounded shadow"/>
<img src="/img/main_advanced_dark.png" className="hidden dark:block rounded shadow"/>

## Configurer le runner

[`setupRunner`](https://doc.melodium.tech/latest/en/cicd/runners/setupRunner.html) prend différents paramètres, dont les principaux sont :
- `name`, une chaîne avec laquelle tous les logs seront marqués ;
- `memory`, mémoire (en mébioctets) dédiée au moteur Mélodium ;
- `cpu`, quantité de CPUs (en millicores) que le moteur Mélodium doit avoir ;
- `storage`, espace disque (en mébioctets) dont dispose le moteur Mélodium ;
- `volumes`, tableau de volumes que le moteur Mélodium et les conteneurs peuvent partager sur le runner ;
- `containers`, liste de conteneurs disponibles pour exécuter des étapes sur le runner.

Les volumes sont essentiellement des labels associés à une taille (en mébioctets), et peuvent être montés dans les conteneurs pour partager des données avec eux.
Les conteneurs sont définis comme suit :
```rust
|container(name, memory, cpu, storage, arch, mounts, image, pull_secret)
```
- `name` étant le nom désigné avec lequel le conteneur peut être adressé comme exécuteur ;
- `memory`, `cpu` et `storage` ayant la même signification que pour le moteur Mélodium ;
- `arch` désignant l'architecture matérielle sur laquelle le conteneur doit s'exécuter ;
- `mounts` étant un tableau de points de montage pour les volumes définis dans le système de fichiers du conteneur ;
- `image` l'image de conteneur à utiliser comme base ;
- `pull_secret` le secret (optionnel) à utiliser pour récupérer l'image de conteneur.

> Le moteur Mélodium lui-même peut être assez économe en ressources car le travail en CI/CD est généralement effectué dans des conteneurs, ne laissant que l'orchestration et le streaming de données. Ainsi, 0,1 CPU et 100 Mio sont de bonnes valeurs par défaut.

> Actuellement les architectures AMD64/x86_64 `|amd64()` et ARM64/aarch64 `|arm64()` sont supportées, et tous les conteneurs dans un même runner doivent utiliser la même architecture.

> Tous les volumes montés dans les conteneurs doivent tenir dans le stockage du conteneur lui-même. Alors que les valeurs de CPU et mémoire sont cumulatives entre le moteur principal et les conteneurs, l'espace de stockage correspondant aux volumes est partagé et non dupliqué entre les conteneurs.

## Exécuter des étapes

Sur chaque runner, un nombre arbitraire d'étapes peut être appliqué en utilisant les traitements [`stepOn`](https://doc.melodium.tech/latest/en/cicd/steps/stepOn.html) et [`stepOnWithInput`](https://doc.melodium.tech/latest/en/cicd/steps/stepOnWithInput.html).
Ces traitements prennent un [`CicdRunnerEngine`](https://doc.melodium.tech/latest/en/cicd/runners/index.html) sur lequel le travail sera effectué, selon la logique suivante :
1. réception du fichier de données en entrée (pour [`stepOnWithInput`](https://doc.melodium.tech/latest/en/cicd/steps/stepOnWithInput.html)),
1. traitement des commandes,
1. émission du fichier de données en sortie.

### Données en entrée

[`stepOnWithInput`](https://doc.melodium.tech/latest/en/cicd/steps/stepOnWithInput.html) dispose de deux paramètres configurant quel fichier est écrit : `in_filesystem` et `in_file` indiquent respectivement quel volume et quel nom de fichier sont remplis avec les données provenant de l'entrée `data`.

Ici le fichier `"list.txt"` est écrit sur le volume `"tested-data"` et accessible au point de montage `"/mounted/data/"` de l'exécuteur `"alpine"` :
```rust
makeTest: stepOnWithInput[runner=runner](
    executor_name="alpine",
    in_filesystem="tested-data",
    in_file="list.txt",
    commands=[
        |command("test", ["-s", "/mounted/data/list.txt"]),
        |command("cat", ["/mounted/data/list.txt"])
    ]
)
```

### Traitement des commandes

Le paramètre `commands` est une liste de commandes exécutées sur l'exécuteur désigné par `executor_name`, dans un `environment` optionnellement défini.

Les commandes peuvent être spécifiées de plusieurs façons :
- fonction [`|command()`](https://doc.melodium.tech/latest/en/process/command/|command.html), pour une commande détaillée avec liste d'arguments ;
- fonction [`|raw_command()`](https://doc.melodium.tech/latest/en/process/command/|raw_command.html), pour une commande en chaîne brute ;
- fonction [`|raw_commands()`](https://doc.melodium.tech/latest/en/process/command/|raw_commands.html), pour une liste complète de commandes en chaîne.

`environment` peut également être fourni pour spécifier des variables d'environnement supplémentaires ou le répertoire de travail.
L'environnement est appliqué à toutes les commandes d'une étape donnée.

```rust
gitClone: stepOn[runner=runner](
    executor_name="ubuntu",
    environment=|wrap<Environment>(|environment(|map([]), "/root", false, false)),
    commands=[
        |command("apt-get", ["update"]),
        |command("apt-get", ["install", "-y", "git"]),
        |command("git", ["config", "--global", "url.https://.insteadOf", "git://"]),
        |command("git", ["clone", "--branch", repository_clone_ref, "--depth", "1", repository_clone_url, "project"])
    ]
)
```

### Données en sortie

Les traitements [`stepOn`](https://doc.melodium.tech/latest/en/cicd/steps/stepOn.html) et [`stepOnWithInput`](https://doc.melodium.tech/latest/en/cicd/steps/stepOnWithInput.html) permettent tous deux de sortir des données. `out_filesystem` et `out_file` spécifient quel volume et quel fichier sont streamés après les commandes de l'étape.

Ici le fichier `"files-list.txt"` est streamé depuis le volume `"build-result"` après l'exécution des commandes :
```rust
makeList: stepOn[runner=runner](
    executor_name="ubuntu",
    environment=|wrap<Environment>(|environment(|map([]), "/root/project", false, false)),
    commands=|raw_commands([
        "sh -c \"ls -l --almost-all | tee files-list.txt\"",
        "mv files-list.txt /mounted/result/"
    ]),
    out_filesystem="build-result",
    out_file="files-list.txt"
)
```

## Exécuter le CI/CD localement

Pour exécuter le programme CI/CD, invoquez Mélodium avec les paramètres du programme :
```sh
melodium run .melodium-ci/Compo.toml advanced --api_token <VOTRE_TOKEN_RUN_API> --output_directory /votre/répertoire/de/sortie --repository_clone_url <URL_CLONE_COMPLETE>.git --repository_clone_ref <BRANCHE_OU_TAG>
```

Où `VOTRE_TOKEN_RUN_API` est un token Run de Cadence.CI. Cela exécute le "moteur principal" du CI/CD depuis l'ordinateur local et distribue le travail sur des workers distants.

Tous les logs CI/CD sont affichés dans le terminal, et les données sont écrites dans `/votre/répertoire/de/sortie`.

## Déployer des clusters (français)

- [Cluster auto-géré](https://cadence.ci/fr/docs/clusters/self-managed.md): Déployer un cluster Mélodium auto-géré sur votre propre infrastructure Kubernetes via le Kubernetes Controller.
- [Cluster Scaleway](https://cadence.ci/fr/docs/clusters/scaleway.md): Module Terraform tout-en-un pour déployer un cluster Mélodium sur Scaleway.

### Cluster auto-géré

> Déployer un cluster Mélodium auto-géré sur votre propre infrastructure Kubernetes via le Kubernetes Controller.

Source: https://cadence.ci/fr/docs/clusters/self-managed
Preferred fetch: https://cadence.ci/fr/docs/clusters/self-managed.md

Il est possible de déployer des clusters auto-gérés avec Mélodium et Kubernetes.
Un contrôleur Kubernetes est disponible pour configurer l'interaction entre Kubernetes et l'API de distribution Mélodium.

## Configurations disponibles

Bien que tout fournisseur Kubernetes devrait être capable de faire tourner un cluster Mélodium, certaines configurations sont disponibles sous forme de modules Terraform pour créer et gérer des clusters entièrement fonctionnels. Celles-ci sont disponibles dans les pages suivantes.

### Cluster Scaleway

> Module Terraform tout-en-un pour déployer un cluster Mélodium sur Scaleway.

Source: https://cadence.ci/fr/docs/clusters/scaleway
Preferred fetch: https://cadence.ci/fr/docs/clusters/scaleway.md

Mélodium fournit un module Terraform tout-en-un pour déployer des clusters sur [Scaleway](https://www.scaleway.com/) :
[`scaleway-kubernetes-cluster`](https://registry.terraform.io/modules/melodium-tech/scaleway-kubernetes-cluster/melodium).

> [!NOTE]
>
> Vous avez besoin de Terraform installé pour suivre ces étapes. Consultez [Terraform.io](https://www.terraform.io/) si vous ne l'avez pas encore.

## S'authentifier avec Scaleway

Pour utiliser le provider Terraform Scaleway, les variables d'environnement `SCW_ACCESS_KEY` et `SCW_SECRET_KEY` doivent être définies.
Référez-vous à la section [Authentication](https://registry.terraform.io/providers/scaleway/scaleway/latest/docs#authentication) du provider Terraform Scaleway pour procéder.

## S'authentifier avec un token de cluster

Dans votre compte, allez dans _Tokens_ > _Cluster Tokens_ et cliquez sur _New Token_ pour générer un nouveau token utilisable pour les clusters.

## Créer la configuration Terraform

Créez un nouveau répertoire et écrivez dans un fichier nommé `main.tf` le contenu suivant :
```terraform

module "scaleway-kubernetes-cluster" {
  source  = "melodium-tech/scaleway-kubernetes-cluster/melodium"
  version = "0.0.3"
  
  // UUID du projet (disponible dans la Console Scaleway près du nom du projet)
  project_id = "<YOUR PROJECT ID>" 
  
  cluster_name = "beautiful-test-cluster"
  cluster_description = "Cluster test on Scaleway"
  cluster_token = "<YOUR CLUSTER TOKEN>"

  /*
  Autres variables disponibles :

  region = "fr-par"
  zone = "fr-par-2"
  cluster_work_pools = {
    "arm-4C-16G" = {
      node_type = "COPARM1-4C-16G" // Type de nœud Scaleway
      volume_size = 80 // Disque en Go
      min_size = 0 // Nombre minimal de machines présentes à tout moment dans ce pool
      max_size = 4 // Nombre maximum absolu de machines dans ce pool
    },
    "amd-4C-16G" = {
      node_type = "GP1-XS"
      volume_size = 80
      min_size = 0
      max_size = 4
    }
  }
  */
  
}

```

## Lancer Terraform

Exécutez les commandes suivantes dans un terminal dans le dossier contenant `main.tf` :

```sh
terraform init
terraform apply
```

Une fois l'opération terminée, votre nouveau cluster est prêt et vos jobs distribués Mélodium lui seront envoyés.

## Supprimer le cluster

Quand vous souhaitez supprimer le cluster, exécutez :
```sh
terraform destroy
```
Cela supprimera toutes les ressources associées au cluster et le désactivera dans l'API de distribution Mélodium.

## Blog (français)

- [Blog](https://melodium.tech/fr/blog): Actualités et articles sur Mélodium et Cadence CI.