Fix GitHub release creation silently dropping tag_name under Native AOT

[Mpdreamz]

What

Creating a GitHub release (create-release) from the AOT-published release-notes tool has been failing on GitHub's side with:

Octokit.ApiValidationException: {"message":"Invalid request.\n\n\"tag_name\" wasn't supplied.","status":"422"}

even though the call site (new NewRelease(config.Version)) clearly sets it, and config.Version is confirmed non-empty.

Root cause

Octokit.Internal.SimpleJsonSerializer serializes request bodies via raw, completely unannotated reflection (type.GetRuntimeProperties(), no [DynamicallyAccessedMembers] anywhere in Octokit/SimpleJson.cs or its reflection helpers). Under Native AOT trimming, the linker can't statically prove which reflected members are needed, so it strips metadata for properties it can't safely classify — in practice, this hits any property with mixed accessor visibility.

NewRelease.TagName is public string TagName { get; private set; } — the only property, across every request model this tool sends (NewRelease, ReleaseUpdate, NewLabel, LabelUpdate), with a non-public accessor. Every other property involved is plain { get; set; } and survives trimming fine.

I confirmed the mechanism directly: publishing a minimal repro with IL trimming enabled and calling SimpleJsonSerializer.Serialize(new NewRelease(...)) throws:

System.NullReferenceException
   at Octokit.PropertyOrField..ctor(PropertyInfo propertyInfo)
   at Octokit.Internal.SimpleJsonSerializer.GitHubSerializerStrategy.GetterValueFactory(Type type)

because GetGetterMethodInfo(propertyInfo) returns null for TagName once its getter metadata is trimmed. The fully AOT-compiled build (as opposed to plain IL trimming) degrades more gracefully and just silently omits the field from the JSON instead of crashing — which is exactly what GitHub's 422 response showed.

This is unrelated to the Octokit version — 14.0.0 is already latest on NuGet, and the bug is structural (no JsonSerializerContext/source-gen support in Octokit's request serialization at all).

Fix

Bypass Octokit only for the Create call — the one place this tool serializes a model with a mixed-visibility property. GitHubReleaseClient.CreateRelease POSTs directly via HttpClient, using a source-generated System.Text.Json.JsonSerializerContext (fully AOT-safe by construction, no reflection at all).

Everything else keeps using Octokit's GitHubClient unchanged (GetLatest/Get for checking existing releases, Repository.Release.Edit with ReleaseUpdate, and the labeling calls) — those request/response models are all plain public get/set, so they aren't affected by this trimming behavior.

Verification

Built a standalone repro of the exact JsonContent.Create(..., JsonSerializerContext) pattern used here, published it fully native-AOT for linux-x64 in a clean mcr.microsoft.com/dotnet/sdk:10.0 container, and posted it against a local HttpListener:

SERVER RECEIVED: {"tag_name":"0.14.1-aot-test","body":"hello"}
STATUS: Created

confirming tag_name now survives AOT compilation end-to-end.

Also included

Rebased onto current master, which already carries the .any-package generateApiChanges fix from a previous PR (turned out cherry-picking it here was a no-op — it's already there).

Made with Cursor