Build & ship · CI
CI
Continuous integration and job scheduling live inside the platform itself, so a package's tests run without wiring up an outside service.
What it is
CI is a first-party part of NAOMS, built into the platform itself. A pipeline defined for a repository runs a candidate change's tests inside a locked, isolated work area, and a scheduler inside the platform is what actually kicks a run off. You do not stand up your own build server or account with a separate provider.
The same isolated work area is reused for a full pipeline run and for running a single test on demand, so the two modes cannot quietly disagree about what "isolated" means.
A run is spawned as an ordinary local process on the machine doing the work, without depending on OS-specific tools that are missing or renamed across platforms. The aim is that a run behaves the same on whichever machine is doing the building.
A single test reuses the exact same test invocation the full pipeline uses, so a result you get from running one test yourself is comparable to what a full run would report for that test.
What a person using the package notices
Nothing directly. The effect is downstream: a release that a hive's quality policy requires a passing CI run for will carry that record, and a hive can be configured to hold back or flag a version that never had one. A person browsing packages sees only the outcome of that policy.
What you do as a developer
You do not maintain a build server. A pipeline is defined for your repository once, and after that, changes trigger it automatically.
Define the pipeline once
A repository's pipeline is a small definition of the stages a candidate change needs to pass, kept with the repository it belongs to.
Let the scheduler run it
The platform's own job scheduler runs the pipeline in its isolated work area; you do not start or monitor a separate CI process by hand.
Reproduce a verdict, or check one file
You can re-run a whole pipeline against a specific commit to reproduce a merge-gate result exactly, or run just one test in the same isolated area while you are iterating on a single change, without setting up a whole pipeline just to run that one test.
How it relates to other steps
Test
CI is what runs your package's tests automatically; Test is the record that comes out of it.
Distribute
A distribution decision reads the test and security-scan records CI produced before letting a release announce itself as available.
Marketplace & hubs
The quality policies a hub enforces (test coverage, known vulnerabilities and the rest) are configured per hive, and CI is what feeds them evidence.