Ci align release gate - #16
Merged
Merged
Conversation
Every repository already had the same skeleton — a version job, a reusable build.yml, a publish job — but five different ways of telling build.yml "this is a release, the checks already ran". Net.Agora used `track != ""`, the Datadog and OpenTok repos used `build-sample` and `verify-release`, Red5Pro inverted its `run-live-tiers` knob, and six repositories had no gate at all and re-ran the entire pull-request pipeline on every tag. Replaces all of it with one boolean input, `verify`, with the same name, default and meaning everywhere. Pull requests leave it true and are the only place verification runs; release.yml passes false. Across the eighteen repositories that takes the build jobs a tag runs from 59 to 23 — the 23 being pack, its prerequisites, and OpenTok.Net's add-windows-assets, which merges the Windows heads into the packages being published and so is not a check. The same rule now applies whether a check is a job or a step: the package tests and sample compiles that lived inside pack jobs are gated too, since where a check happened to be written should not decide whether it repeats. Checks on the pins a pack consumed, or on the bytes it emitted, still run on a release — they are cheap and they guard the artifact about to be published. Skipping verification on a tag is only sound if the tagged commit really did go through a pull request, so release.yml gains a guard job that fails when the commit is not an ancestor of the default branch. OpenTok.Net.Android and OpenTok.Net.iOS also gain the tag-versus-Directory.Build.props check their sibling OpenTok.Net.Win already had. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The tag was the only manual step left. A release note is already written by hand, one per version, as part of the pull request that bumps the pins — so merging that note is the decision to release, and everything after it was mechanical: cut a tag whose name has to match the note's filename exactly, and push it. auto-release.yml does that. On a push to the default branch touching docs/release-notes/**, it takes the notes the push ADDED (not modified — editing an old note is a correction, not a release), derives each tag from the filename, and tags the merge commit. Two filename conventions, matching what each repository already does: bare version here, so 2.34.1.4.md tags v2.34.1.4. It then dispatches release.yml at the new tag rather than relying on the tag push to trigger it. That is not a stylistic choice: a tag pushed with GITHUB_TOKEN deliberately does not fire `on: push: tags`, so release.yml would never start. workflow_dispatch is documented as an exception that always creates a run, so release.yml gains a workflow_dispatch trigger; dispatched at the tag's ref, github.ref_name is the tag and every version, track, notes and changelog lookup in there behaves exactly as it does today. Stricter than the manual path on purpose. release.yml accepts a three-part version; this accepts only four parts, because every release tag any of these repositories has carried is four-part while the three-part notes that exist (2.17.2.md, 8.1.7.md, 8.1.2.md) are series overviews. Replayed over every commit that ever added a note: 77 resolve to the tag that actually exists, and the only rejections are those three overviews. Re-running is a no-op — a tag that already exists is skipped. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The sample set no RuntimeIdentifiers, so it inherited the .NET Android SDK default, which still lists the 32-bit android-arm and android-x86. FFmpegKit ships arm64-v8a and x86_64 only, so that build packages two ABIs with no libffmpegkit.so in them: a 32-bit device installs the app and crashes on first use. FFMPEGKIT002, raised by the .targets the Android package ships, has been saying so on every sample build. Set rather than suppressed. The sample is what a consumer copies, so silencing the diagnostic here would teach exactly the mistake the diagnostic exists to prevent — and 64-bit-only is what a consuming app should ship regardless, the Play Store having required a 64-bit slice since 2019. NoWarn remains the right answer for the case the .targets comment already describes: an app that keeps 32-bit runtime identifiers for other reasons and gates its FFmpegKit calls at runtime. That is not this sample. No coverage lost: the emulator suite runs x86_64, which android-x64 covers, and the Release link check builds arm64. Verified against the shipped .targets directly — with the SDK default list it reproduces the CI warning verbatim, with android-arm64;android-x64 it is silent, and lowering SupportedOSPlatformVersion still raises FFMPEGKIT001, which proves the check is running rather than being skipped. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.