Set up CI/CD for the nanoFramework.NET.Sdk repository (build, test, pack, publish)

[danielmeza]

Description

The nanoFramework.NET.Sdk repository has no CI/CD. Unlike the other org repositories (for example nf-Visual-Studio-extension and Samples, which carry an azure-pipelines.yml and GitHub Actions workflows), it has no Azure Pipelines definition, no GitHub Actions workflow, and no nfbot wiring. It does have version.json (Nerdbank.GitVersioning), but nothing consumes it.

This has two consequences on the critical path. First, the SDK repository's pull requests are not validated automatically: the SDK build, the SmokeTest, and the migration/tool test suites (over a hundred tests) do not run on push or PR. Second, the planned "publish the SDK to nuget.org" step has no automation behind it — there is no pipeline to pack and push the nanoFramework.NET.Sdk package (nor the nanoFramework.Tool / nanoFramework.Migrate tools), and nfbot versioning/changelog-on-merge cannot run without the pipeline.

How to solve the problem

Stand up CI/CD for the repository, modeled on the existing org repositories:

• Continuous integration that restores, builds the SDK (src/nanoFramework.NET.Sdk) and the tools, and runs the test suites (NanoMigrate.Tests, the umbrella tool tests) and the SmokeTest, on pull requests and on pushes to move-to-sdk / the release branch.
• Packaging that produces the nanoFramework.NET.Sdk NuGet package (and optionally the nanoFramework.Tool and nanoFramework.Migrate tool packages), versioned via the existing version.json (Nerdbank.GitVersioning).
• A gated publish step to nuget.org on release, with nfbot handling versioning/changelog on squash-merge per the org convention.
• A GitHub Actions build/test workflow is a reasonable first step because it runs immediately on the fork and gives PR validation without org infrastructure; the Azure Pipelines definition is the org-standard publish path.

Acceptance: pull requests run a build + full test pass automatically; a merge to the release branch produces the SDK NuGet package; the gated publish step pushes it to nuget.org; nfbot versions/changelogs on merge.

Describe alternatives you've considered

• Continue building and publishing manually. Rejected: the PRs go unvalidated and the "publish the SDK" gate (which the whole rollout depends on) has no repeatable path; manual publishing is error-prone and diverges from every other org repo.
• GitHub Actions only. A good immediate PR-validation gate, but the org standard for publishing/signing/nfbot is Azure Pipelines; both can coexist (Actions for PR validation, Azure for publish).

Additional context

• The pieces that need org infrastructure — nfbot service connections, signing certificates, the nuget.org push token, and the org's pipeline templates — are maintainer-owned; the pipeline can be scaffolded with those left as clearly marked setup steps.
• Critical-path context and PR strategy: EXECUTION-PLAN.md; phasing in 09 — implementation strategy.
• Parent epic: SDK-style MSBuild project system for .NET nanoFramework #1784.
• Scope: nanoFramework.NET.Sdk repo. Phase 1; unblocks the "publish the SDK" gate that Samples and the fleet depend on.