Repository navigation
Open
Labels
target/backlogNo committed release year; long-tail / demand-drivenNo committed release year; long-tail / demand-driven
Milestone
Description
Sub-issue under #73 (umbrella modularization). Sibling to #72 (tools split).
Scope
src/Fallout.Common/CI/ currently bundles all 11 CI provider integrations into a single package. Split each into its own Fallout.CI.<Provider> project + NuGet package.
| Today | New |
|---|---|
src/Fallout.Common/CI/AppVeyor/ |
src/Fallout.CI.AppVeyor/ → Fallout.CI.AppVeyor package |
src/Fallout.Common/CI/AzurePipelines/ |
src/Fallout.CI.AzurePipelines/ → Fallout.CI.AzurePipelines package |
src/Fallout.Common/CI/Bamboo/ |
src/Fallout.CI.Bamboo/ → Fallout.CI.Bamboo package |
src/Fallout.Common/CI/Bitbucket/ |
src/Fallout.CI.Bitbucket/ → Fallout.CI.Bitbucket package |
src/Fallout.Common/CI/Bitrise/ |
src/Fallout.CI.Bitrise/ → Fallout.CI.Bitrise package |
src/Fallout.Common/CI/GitHubActions/ |
src/Fallout.CI.GitHubActions/ → Fallout.CI.GitHubActions package |
src/Fallout.Common/CI/GitLab/ |
src/Fallout.CI.GitLab/ → Fallout.CI.GitLab package |
src/Fallout.Common/CI/Jenkins/ |
src/Fallout.CI.Jenkins/ → Fallout.CI.Jenkins package |
src/Fallout.Common/CI/SpaceAutomation/ |
src/Fallout.CI.SpaceAutomation/ → Fallout.CI.SpaceAutomation package |
src/Fallout.Common/CI/TeamCity/ |
src/Fallout.CI.TeamCity/ → Fallout.CI.TeamCity package |
src/Fallout.Common/CI/TravisCI/ |
src/Fallout.CI.TravisCI/ → Fallout.CI.TravisCI package |
Each package contains:
- The
[<Provider>]configuration-generator attribute (e.g.[GitHubActions(...)],[TeamCity(...)]) - The YAML/Kotlin/XML configuration model classes
- Any provider-specific environment helpers (e.g.
GitHubActions.Instancestatic accessor forGITHUB_*env vars during a CI run) - Per-provider integration helpers (test reporters, artifact uploaders, etc.)
A new Fallout.CI.Abstractions package may emerge for the shared base classes (ConfigurationAttributeBase, ConfigurationGenerationGenerator, etc.) that every provider package depends on. Decision during implementation.
Mechanical plan
- Decide on
Fallout.CI.Abstractions— yes / no. If yes, what's in it. - Create per-provider projects under
src/Fallout.CI.<Provider>/. Each referencesFallout.Common(orFallout.CI.Abstractionsif introduced). git mvfiles preserving history; rename namespacesFallout.Common.CI.<Provider>→Fallout.CI.<Provider>.- Update
fallout.slnx+Directory.Packages.props. - Update
Build.cssource for this repo ([GitHubActions]attribute usage onBuild). - Update CI generation templates ([P6] Update CI generation templates and tool-wrapper JSON references #39 already touched this — verify).
- Per-provider tests under
tests/Fallout.CI.<Provider>.Tests/. - Update
fallout-migrateto rewrite namespaces + add the matching<PackageReference>. - Update
Nuke.Commonshim — either re-export fromNuke.Common.CI.<Provider>(lots of subclassing) or ship matchingNuke.CI.<Provider>shim packages. - Migration guide entry ([P5] Write NUKE → Fallout migration guide #37).
Migration impact
- Breaking for consumers. New
<PackageReference Include="Fallout.CI.GitHubActions" />+using Fallout.CI.GitHubActions;instead ofusing Fallout.Common.CI.GitHubActions;. Both mechanical,fallout-migrateshould handle. - 11.0-aligned. Batch with Split tool wrappers out of Fallout.Common into per-tool projects + NuGet packages #72 and the legacy-name removals.
Done when
- All 11 CI providers split into their own projects + packages
-
fallout.slnx+Directory.Packages.propsupdated - This repo's own
Build.csconsumes the new packages - Per-provider tests pass
-
fallout-migratecovers the namespace + PackageReference migration -
Nuke.Commonshim still works (or per-provider shim packages exist) - Release pipeline ships all 11
Fallout.CI.*packages - Migration guide updated
Metadata
Metadata
Assignees
Labels
target/backlogNo committed release year; long-tail / demand-drivenNo committed release year; long-tail / demand-driven
Activity