You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CLAUDE.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -97,7 +97,7 @@ Skipping or reordering these steps is not acceptable—they keep our feedback lo
97
97
98
98
## Project Overview
99
99
100
-
`cigen` is a Rust CLI tool that generates CI pipeline configurations from templates. It integrates with Nx monorepo tooling and supports multiple CI providers starting with CircleCI.
100
+
`cigen` is a Rust CLI tool that generates CI pipeline configurations from templates. It is migrating to a plugin-based architecture that currently targets GitHub Actions for our self-hosting work, with CircleCI support being rebuilt on top of the same system.
101
101
102
102
See `PRD.txt` for the complete product requirements and specifications.
103
103
@@ -352,7 +352,7 @@ You can also reference `/Users/ndbroadbent/code/docspring/lib/tools/generate_cir
352
352
353
353
## Use Our Own Tool
354
354
355
-
The goal is to eventually become 'self-hosting' for our own CI pipeline on GitHub Actions. We must have `nx.json` and `project.json` file in the root of the repository, a `.cigen/`directory, and a `.cigen/config.yml` file.
355
+
The goal is to eventually become 'self-hosting' for our own CI pipeline on GitHub Actions. We already keep `turbo.json` and other workspace metadata in the repo alongside `.cigen/`so that the CLI can evolve toward Turborepo-aware features.
356
356
357
357
We will start by hand-writing our own GitHub Actions workflow files, but eventually migrate to using `cigen` to generate our CI configuration.
358
358
@@ -395,6 +395,6 @@ We MUST use split config for large configuration sections:
395
395
396
396
## Key Concepts
397
397
398
-
- The tool reads Nx `project.json` files to understand project dependencies and file groups
398
+
- The tool no longer relies on the old workspace-specific metadata that was tied to previous experiments. Future monorepo integrations will be driven by the plugin system (e.g., Turborepo) once the orchestration layer is complete.
399
399
- Templates and configuration live in the `.cigen/` directory
400
400
- The tool supports plugin-based cache backends and CI provider emitters
Copy file name to clipboardExpand all lines: README.md
+17-24Lines changed: 17 additions & 24 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,28 +1,25 @@
1
1
# CIGen
2
2
3
-
CIGen generates CI configuration from a small set of reusable, provider-agnostic files. It currently targets CircleCI and focuses on correctness, validation, and convention-over-configuration.
3
+
CIGen generates CI configuration from reusable, provider-agnostic files. The project is undergoing a major migration to a Terraform-style plugin architecture: the new Rust core spawns provider binaries over a length-prefixed stdio transport, and those plugins emit provider-specific YAML.
4
4
5
-
The tool can generate both static CircleCI configs and setup/dynamic configs. The CLI includes utilities for validation, graph visualization, and template-based multi-output generation.
5
+
Today the GitHub Actions provider plugin powers our own CI (`cargo run -- generate --file .cigen`), while the legacy CircleCI emitter is being rebuilt on top of the same plugin system. The CLI still provides the templating, schema validation, and hashing utilities that powered the earlier monolithic implementation.
6
6
7
7
## Features (Current)
8
8
9
-
- CircleCI provider support (config generation and validation)
10
-
- Rust implementation for reliability and performance
11
-
- Template-based multi-output generation (Jinja-like via MiniJinja)
12
-
- Built-in defaults for package/version detection (extensible via YAML)
13
-
- Package installation step generation and job deduplication
14
-
- Basic automatic cache step injection when `job.cache` is declared
15
-
- Architecture variants per job (e.g., `build_amd64`, `build_arm64`)
16
-
- Advanced git checkout: shallow clone by default with configurable clone/fetch options, host key scanning, and path overrides
17
-
- Descriptive error messages and schema/data validation ([miette], JSON Schema)
18
-
- Opt-in Docker builds with a single BASE_HASH and image DAG
9
+
- Plugin manager (`src/plugin/`) with framing helpers, handshake workflow, and async request batching
10
+
- GitHub Actions provider plugin (`plugins/provider-github`) that generates the workflows under `.github/workflows/`
11
+
- Source file grouping and job-hash based skipping backed by `actions/cache`
12
+
- Template-based multi-output generation (MiniJinja) for additional artefacts
13
+
- Rich schema validation using JSON Schema + miette diagnostics
@@ -50,17 +47,13 @@ We automatically add a highly-optimized git checkout step to the beginning of ea
50
47
51
48
#### Job skipping
52
49
53
-
The codebase contains an initial scaffold for job skipping using a source-file hash and a local marker file. This is experimental and not yet wired to a persistent cache backend, so it does not skip across separate runs. A robust, persistent job-status cache is planned.
50
+
Jobs that declare `source_files` automatically receive a skip cache flow. On GitHub Actions this uses `cigen hash` plus `actions/cache`; jobs exit early when nothing changed and record a marker when they succeed. The preflight hook and remote signature storage are still planned so that other providers can share the same mechanism.
54
51
55
52
#### Cross-platform CI config
56
53
57
54
CI providers often solve the same problem in different ways. e.g. to avoid duplication in your config, GitHub actions has "reusable workflows" while CircleCI supports "commands".
58
55
59
-
`cigen` takes the best ideas from each provider and supports our own set of core features. You write your config once, then we compile it to use your chosen CI provider's native features. This avoids vendor lock-in and makes it easier to migrate to other CI providers.
60
-
61
-
#### You can still use native CI provider features
62
-
63
-
You can still use native CircleCI features (e.g., orbs). Other providers will come later; unsupported features are validated with clear errors.
56
+
`cigen` takes the best ideas from each provider and supports our own set of core features. You write your config once, then we compile it to use your chosen CI provider's native features. As more providers move onto the plugin system, migrations become a matter of switching emitters instead of rewriting YAML.
0 commit comments