Fallout-build / Fallout-build/Fallout
Multi-provider CI revival — gather demand for Azure / GitLab / TeamCity / AppVeyor support
- Dominant language
- C#
- Stars
- 154
- Forks
- 19
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 15
Description
## Context
We dropped Azure Pipelines, GitLab CI, TeamCity, and AppVeyor support from this repo's own CI in #TBD (the purge PR). **This does not remove NUKE's ability to *generate* configs for those providers** — that lives in `source/Nuke.Common/CI/*` and is consumed by NUKE users, not by this repo's pipeline.
What we dropped is NUKE dogfooding itself on those providers. The repo's release/validation now runs through GitHub Actions only.
## Question to answer
Do real NUKE users still rely on those generators? And do they expect them smoke-tested by NUKE's own CI on every release? If yes, revive at least one as a sample/test surface. If no (or "rarely"), the generator code can move into separate add-in packages installed on demand.
## How to answer
- Open a Slack/Discord poll
- Add a quick survey to nuke.build/docs
- Watch the GitHub-Actions-vs-X label distribution on incoming issues over ~2 months
- Talk to the top 5 NUKE users by GitHub stars / NuGet downloads
## Possible outcomes
1. **Revive one provider** as the canonical alt (likely TeamCity — JetBrains historically gave NUKE a free TC Cloud instance).
2. **Move provider integrations into add-in packages** (`Nuke.CI.AzurePipelines`, `Nuke.CI.GitLab`, etc.) that users opt into. Cleaner separation, no core maintenance burden.
3. **Drop entirely**, keeping only GitHub Actions support in core.
Don't action this without a demand signal — that's the whole point.
Contributor guide
Assessment
This issue has not been assessed yet.