Summary
Fallout can already generate CI configuration from C# — [GitHubActions(...)],
[AzurePipelines(...)], etc. on the Build class emit the workflow files
(ConfigurationAttributeBase + IConfigurationGenerator). This issue proposes the
reverse direction: a best-effort importer that reads an existing pipeline
(GitHub Actions *.yml, Azure DevOps azure-pipelines.yml) and scaffolds the
equivalent Fallout build — the attribute declaration plus stub targets — to lower
the cost of migrating an existing repo onto Fallout.
Motivation
Proposed shape
A CLI verb, e.g. dotnet fallout import:
dotnet fallout import --from .github/workflows/ci.yml # autodetect provider
dotnet fallout import --from azure-pipelines.yml --provider azdo
Output (best-effort):
- A
[GitHubActions(...)] / [AzurePipelines(...)] attribute on a generated
Build.CI.*.cs partial, with triggers, branch filters, image/matrix, and
concurrency mapped from the source where they have a 1:1 analogue.
- Stub
Targets for each distinguishable pipeline step/job, with the original
run:/script: body dropped into a comment so the author can port it.
- A migration report listing what mapped cleanly vs. what needs manual attention.
Scope & honesty about limits
This is scaffolding, not a transpiler. CI YAML → typed build targets is lossy:
arbitrary shell, marketplace actions, expression syntax, and matrix fan-out have no
clean 1:1 in a C# build. The deliverable is a head start + a clearly-labelled
"TODO: port manually" report — explicitly not a guarantee of a runnable build.
Suggested phasing
Open questions
- Reuse the existing
Configuration/ object model (currently generation-only) as the
shared intermediate representation, or a separate import model?
- How far to map marketplace actions (
actions/checkout, setup-dotnet) — recognise
a known-set and map to Fallout equivalents, or always emit a TODO?
- GitLab CI / other providers in scope later, or GitHub + AzDO only?
Summary
Fallout can already generate CI configuration from C# —
[GitHubActions(...)],[AzurePipelines(...)], etc. on theBuildclass emit the workflow files(
ConfigurationAttributeBase+IConfigurationGenerator). This issue proposes thereverse direction: a best-effort importer that reads an existing pipeline
(GitHub Actions
*.yml, Azure DevOpsazure-pipelines.yml) and scaffolds theequivalent Fallout build — the attribute declaration plus stub targets — to lower
the cost of migrating an existing repo onto Fallout.
Motivation
to a C# build is manual busywork." An importer turns that into a one-shot scaffold
the user then refines.
generator becomes the source of truth going forward (generate-then-commit, same as
today).
Proposed shape
A CLI verb, e.g.
dotnet fallout import:Output (best-effort):
[GitHubActions(...)]/[AzurePipelines(...)]attribute on a generatedBuild.CI.*.cspartial, with triggers, branch filters, image/matrix, andconcurrency mapped from the source where they have a 1:1 analogue.
Targets for each distinguishable pipeline step/job, with the originalrun:/script:body dropped into a comment so the author can port it.Scope & honesty about limits
This is scaffolding, not a transpiler. CI YAML → typed build targets is lossy:
arbitrary shell, marketplace actions, expression syntax, and matrix fan-out have no
clean 1:1 in a C# build. The deliverable is a head start + a clearly-labelled
"TODO: port manually" report — explicitly not a guarantee of a runnable build.
Suggested phasing
Build.CI.*.csemitter (reuse the existingConfiguration/object graph where possible).importCLI verb + migration report.Open questions
Configuration/object model (currently generation-only) as theshared intermediate representation, or a separate import model?
actions/checkout,setup-dotnet) — recognisea known-set and map to Fallout equivalents, or always emit a TODO?