|
| 1 | +# Building and releasing packages |
| 2 | + |
| 3 | +The [build workflow](../.github/workflows/build.yml) runs on pushes to `master` and pull requests. It |
| 4 | +builds the whole solution on Windows with .NET 10.0.400 and the MAUI Windows workload, runs the tests |
| 5 | +that need no desktop session, and uploads the `.nupkg` files and test reports as Actions artifacts. |
| 6 | +Tests always have a filter, a two-minute hang timeout and a five-minute session timeout. Assemblies |
| 7 | +run in sequence. |
| 8 | + |
| 9 | +`Contracts`, `Runtime` and `Cli` contain unit tests. `Protocol` exercises a real host and client with |
| 10 | +Avalonia Headless. The Avalonia suite uses headless controls, and the MAUI suite exercises controls |
| 11 | +without their native platform handlers. The MCP surface tests start the server without opening an |
| 12 | +application window. |
| 13 | + |
| 14 | +The WPF screenshot tests and MCP application tests open real windows. To include these in CI, register |
| 15 | +a Windows x64 self-hosted runner with the `desktop` label, start it in an interactive desktop session, |
| 16 | +and set the repository variable `DESKTOP_TESTS_ENABLED` to `true`. The runner needs .NET 10.0.400 and |
| 17 | +the MAUI Windows workload. This job runs on trusted branch pushes and release runs; pull requests |
| 18 | +use the hosted runner. Without that configuration, desktop tests can be run locally after a Release |
| 19 | +build: |
| 20 | + |
| 21 | +```powershell |
| 22 | +./.github/scripts/Test.ps1 -Suite Desktop |
| 23 | +``` |
| 24 | + |
| 25 | +## GitHub releases |
| 26 | + |
| 27 | +The [release workflow](../.github/workflows/release.yml) follows the tag or manual release model used |
| 28 | +by [StockSharp/Odysseus](https://github.com/StockSharp/Odysseus/blob/main/.github/workflows/release.yml). |
| 29 | +For DesktopDriver, the assets are NuGet library and .NET tool packages. A release rebuilds, tests and |
| 30 | +packs the tagged source before publishing. All packages use the same version, including dependencies |
| 31 | +between DesktopDriver packages; tests and the sample application are not packed. |
| 32 | + |
| 33 | +To publish version `1.0.0`, push the tag on the commit to release: |
| 34 | + |
| 35 | +```sh |
| 36 | +git tag v1.0.0 |
| 37 | +git push origin v1.0.0 |
| 38 | +``` |
| 39 | + |
| 40 | +Alternatively, open **Actions → release → Run workflow**, enter a version without `v`, and turn off |
| 41 | +`dry_run` to publish. The manual run creates the tag on the selected commit after the build passes. |
| 42 | +Keep `dry_run` enabled to check a release build without creating a tag or release. A version with a |
| 43 | +prerelease suffix, such as `1.0.0-beta.1`, creates a GitHub prerelease. |
| 44 | + |
| 45 | +The workflow uses GitHub's automatic `GITHUB_TOKEN` with write access to repository contents only |
| 46 | +for the publish job. No separate secret is needed for a GitHub release. It publishes `.nupkg` assets |
| 47 | +to GitHub Releases; it does not upload them to NuGet.org. A release version that already exists is |
| 48 | +refused rather than replaced. |
| 49 | + |
| 50 | +## NuGet.org |
| 51 | + |
| 52 | +Publishing to NuGet.org is a separate configuration. It can use |
| 53 | +[NuGet trusted publishing](https://learn.microsoft.com/en-us/nuget/nuget-org/trusted-publishing): |
| 54 | +register this repository and the publishing workflow with the NuGet package owner, then exchange a |
| 55 | +GitHub Actions identity for a short-lived publishing key with `NuGet/login`. A GitHub push credential |
| 56 | +or `GITHUB_TOKEN` does not grant publishing access to NuGet.org. |
0 commit comments