Fallout-build / Fallout-build/Fallout
CI import: migrate GitHub Actions and Azure Pipelines into idiomatic Fallout C#
- 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
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