Skip to content

Multi-provider CI revival — gather demand for Azure / GitLab / TeamCity / AppVeyor support #8

Description

@ChrisonSimtian

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    target/backlogNo committed release year; long-tail / demand-driven

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions