GitLab CI YAML: Versioned Schema Collection📋

GitLab CI YAML contributes declarative pipeline configuration to the software factory. It is included because its Design project references BinaryWrapper.Design.Lib, but its active entry point uses the generic Wrapper.Versioning collection pipeline.

It is a schema-driven configuration library, not another stdout/stderr parser for an executable tool.

Follow the active entry point📋

Program loads dotenv values for the GitLab release collector, normalizes tags such as v18.x.y-ee, and selects the latest patch per minor with a default minimum of 18.0.0.

The generic pipeline downloads a JSON schema from the corresponding GitLab source tag and saves it as gitlab-ci-v<version>.json. The acquisition shape is DesignPipeline<string> with HTTP download/save middleware and DesignPipelineRunner<string>.

A project reference alone does not establish that BinaryWrapper's CLI scraper is the active mechanism. Following imports and constructed types shows which shared pipeline actually runs.

Schema collection differs from CLI scraping📋

The input authority is a GitLab CI JSON schema. No recursive help queries or output profiles are involved.

Network acquisition is an explicit Design operation. Ordinary builds read local schema inputs and do not download them.

A separate build-time generator📋

GitLabCiBundleGenerator is an incremental Roslyn generator. It selects gitlab-ci-*.json AdditionalFiles, reads filename versions, parses schemas and merges their declarations.

It emits schema-version metadata, GitLabCiFile, jobs and nested models, plus builders through the shared Builder emitter. The current descriptor carries [GitLabCiBundle], but the inspected generator's active registration is schema-file driven; it does not use that marker as the BinaryWrapper descriptor discovery path.

The runtime project also embeds schemas and references YamlDotNet for serialization. These are different dependencies from the executable wrappers' Contracts/runtime split.

A complete in-memory configuration📋

The following complete example constructs generated model types and serializes YAML without writing a file or running a pipeline. It uses an illustrative image tag, not a verified artifact.

using FrenchExDev.Net.GitLab.Ci.Yaml;
using FrenchExDev.Net.GitLab.Ci.Yaml.Serialization;

var pipeline = new GitLabCiFile
{
    Stages = new List<object> { "build" },
    Jobs = new Dictionary<string, GitLabCiJob>
    {
        ["build"] = new GitLabCiJob
        {
            Image = "example/sdk:reviewed",
            Script = new List<string> { "dotnet build", "dotnet test" },
        },
    },
};
var yaml = GitLabCiYamlWriter.Serialize(pipeline);
Console.WriteLine(yaml);

The job scripts remain strings because they belong to GitLab's runner script protocol. A typed configuration model does not mean every shell expression within a CI job has been replaced by BinaryWrapper.

Model composition and serialization📋

IGitLabCiContributor lets contributors add stages, jobs and configuration to a shared model. Builders provide another construction path, while the reader can deserialize existing YAML.

The writer handles GitLab's root-level jobs and serialization conventions, including null omission and string/list forms. Round-trip verification should focus on supported semantic shapes, not assume every YAML comment or formatting detail is preserved.

The schema union carries availability metadata. It does not by itself prove acceptance by every GitLab installation with custom behavior. Select and validate the intended server/schema version when generating a deployable pipeline.

Environment is a different concept here📋

There is no BinaryWrapper command environment catalogue or output-parser profile for this schema consumer. DotEnv supplies acquisition credentials to Design.

GitLab CI variables, job environment declarations and runner process settings belong to the CI configuration and execution system. They must not be confused with ICliEnvironment overrides attached to a locally executed BinaryWrapper command.

An application can compose this configuration library with Git and glab wrappers: generate a pipeline, commit it, then observe the server's pipeline/job resources. Those steps have separate contracts and authorization boundaries.

Version and verification boundaries📋

The schema filename version, GitLab server version, glab CLI version and a job's selected SDK/image version can all differ. Tracking them separately is necessary for reproducible software-factory configuration.

Verify schema selection/merging, generated models/builders, YAML writing/reading and contributor behavior. A successful in-memory serialization does not prove server acceptance or pipeline success.

The executable GitLab CLI study covers process observations. This library supplies typed configuration models and YAML serialization through its own schema contract.

Source snapshot📋

Source inspection: 2 October 2026. These implementation paths are relative to Net/FrenchExDev in the local ecosystem checkout. The v2 changes are largely uncommitted; these paths identify inspected code, without claiming that public branch links contain it.

• GitLab.Ci.Yaml/src/FrenchExDev.Net.GitLab.Ci.Yaml.Design/Program.cs
• GitLab.Ci.Yaml/src/FrenchExDev.Net.GitLab.Ci.Yaml/FrenchExDev.Net.GitLab.Ci.Yaml.csproj
• GitLab.Ci.Yaml/src/FrenchExDev.Net.GitLab.Ci.Yaml.SourceGenerator
• Wrapper.Versioning/src/FrenchExDev.Net.Wrapper.Versioning

Previous: WinGet · Implementation index · Series index