Migrate CI generation to DSL-driven architecture (CG-4)

[briansrls]

Summary

Refactor CI workflow generation from Rust-based template rendering to a pure DSL-driven approach. The cmd_cigen() function now builds and executes a tools/cigen.dag DSL graph instead of directly generating YAML strings in Rust. This aligns with the broader goal of moving codegen logic into the DAG language.

Key Changes

• Removed Rust-based CI rendering: Deleted ~260 lines of template generation code (generate_github_actions_template, generate_gitlab_ci_template, validation functions, and related helpers) from codegen_cli.rs.

• Added DSL CI model and rendering: Created two new DSL modules:

  • dsl/std/ci.dag: Type definitions for CI primitives (CiStepKind, CiPermissionLevel, CiProvider) and composition (CiWorkflow, CiConfig)
  • dsl/std/ci_render.dag: Pure rendering functions that convert CiConfig into GitHub Actions and GitLab CI YAML strings

• Added DSL entry point: Created dsl/tools/cigen.dag that orchestrates CI generation:

  • Calls discover_ci_config() extern function to gather permissions, secrets, env, runner, and tool command from Rust
  • Renders both GitHub and GitLab YAML via pure DSL functions
  • Uses content_upsert pattern to write files with change detection

• Implemented extern bridge: Added DiscoverCiConfigOp in extern_impls.rs that builds a CiConfig record from existing Rust CI configuration sources (ci_workflow_permissions(), ci_live_test_secrets(), CargoEnv::ci(), etc.).

• Updated tests:

  • Removed 5 unit tests that validated Rust template generation
  • Added single integration test verifying DSL graph compiles successfully
  • Updated extern symbol baseline and DSL file inventory

• Fixed cross-module service call cloning: Added regression test and fix in daglang-lower to ensure multiple modules calling the same service operation each get their own cloned transport triplet (_c1, _c2, etc.) instead of sharing edges.

Implementation Details

• The DSL rendering functions follow the makegen.dag pattern: small composable functions using |> map and |> join("\n") for YAML construction
• No general YAML serializer; indentation is handled via string literals
• Execution mode (dry-run vs. real) is passed through to the DSL executor
• Output status (written/unchanged/dry-run) is extracted from the execution log
• All CI configuration discovery remains in Rust; only rendering moves to DSL

https://claude.ai/code/session_01RJhmcvqFXK4YDb5zbfaixE

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2e1ea2d67f

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Use GitLab variable syntax for cache key

render_gitlab_cache now emits cargo-${{CI_COMMIT_REF_SLUG}}, but GitLab cache keys use CI variable expansion like $CI_COMMIT_REF_SLUG/${CI_COMMIT_REF_SLUG} (the previous generator in this repo used ${CI_COMMIT_REF_SLUG}). With the current string, the branch slug is not interpolated correctly, so caches won’t partition per ref as intended and CI runs lose cache effectiveness.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Preserve deterministic permission ordering

ci_workflow_permissions() is a HashMap-backed permission set, and this code iterates it directly into a list without sorting. Because the renderer preserves list order, GitHub permissions: entries can appear in different orders across runs, creating nondeterministic generated YAML churn. The old Rust path sorted permissions (RenderConfig::with_permissions), so this is a regression in generator determinism.

Useful? React with 👍 / 👎.