Fallout-build / Fallout-build/Fallout

CI import: migrate GitHub Actions and Azure Pipelines into idiomatic Fallout C#

Open
#429 1 comment 0 reactions 0 assignees View on GitHub
enhancement target/vCurrent
Dominant language
C#
Stars
154
Forks
19
Avg merge
1d 22h
Merged PRs (30d)
15

Description

@
### Problem
Adopting Fallout on a project that already has CI means hand-rewriting every
workflow — there's no path *in*. And moving a pipeline between hosts (GitHub
Actions ⇄ Azure Pipelines) is a full manual rewrite each direction.

### Outcome
A `fallout migrate ` command reads existing CI YAML and emits idiomatic
Fallout C#. The forward generators already exist; this adds the reverse. Once a
project's logic lives in C#, retargeting another host is a regenerated shim
(`./build.ps1 `), not a second migration — Fallout becomes the
translation layer between hosts.

Two buckets on import:
- **Lift** — recognized commands (`dotnet build/test/restore/pack`, …) become
tool-wrapper targets.
- **Stub** — anything unconvertible (marketplace actions, host-native deploy)
becomes a *compiling* target that throws `NotImplementedException`, carrying
the original step and source ref inline for a human to finish.

### Acceptance criteria
- [ ] `fallout migrate github` reads `.github/workflows/*.yml` → emits/updates `Build.cs` + `[GitHubActions]`
- [ ] `fallout migrate azure` does the same for `azure-pipelines.yml` + `[AzurePipelines]`
- [ ] Recognized .NET commands emit idiomatic tool-wrapper targets (e.g. `dotnet test --no-build` → `DotNetTest(s => s.EnableNoBuild())`)
- [ ] Unconvertible steps emit a compiling stub: original step inline + `path:line` ref + `NotImplementedException`
- [ ] `--dry-run` reports lift/stub counts per host, writes nothing
- [ ] Round-trip: regenerating CI from emitted C# diffs cleanly against the original for lifted steps
- [ ] Nothing is silently dropped

### Notes
- Architecture: reuse `ConfigurationEntity` as a shared IR; readers (`IConfigurationReader`) symmetric with the existing `IConfigurationGenerator` writers. Forward side + tool catalog already exist (~half the work).
- Recognizer can ship empty and grow — without it, lifted steps fall back to shell `Executes`; the rest still stubs. So MVP = readers + C# emitter + stub emitter + CLI.
- GitLab and other hosts out of scope for first cut.
@

Contributor guide

Open the contributing guide

Research direction

Start by reading ConfigurationEntity, the existing IConfigurationGenerator writers, and the CLI entry point. Trace the forward generators and tool catalog before adding symmetric readers for GitHub Actions and Azure Pipelines. Done means Build.cs output, compiling stubs, dry-run lift/stub counts, clean lifted round-trips, and no silently dropped steps.

Written by the indexing model from the issue text.

Assessment

Tech stack
azure, csharp, github-actions
Domain
build-system, ci-cd, cli
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.