Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughReworks release workflow to dry-run/manual semantics, enforces tag-on-master validation for official releases, changes artifact publishing to push commits (emit Changes
Sequence Diagram(s)sequenceDiagram
participant Tag as Tag Event
participant WF as Release Workflow
participant Git as Git (origin)
participant Build as Build/Artifacts
participant Repo as GitHub Repo
Tag->>WF: trigger release job
WF->>Git: resolve tag -> tag_commit
WF->>Git: fetch origin/master
WF->>Git: check if tag_commit is reachable from origin/master
alt tag on master
WF->>Build: build artifacts
Build->>Repo: push artifact commit to `master` (artifact_commit_url)
WF->>Repo: create release draft (non-prerelease/manual)
Repo-->>WF: release draft URL
else tag not on master
WF-->>Tag: fail job (tag must be on master for official release)
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
Updates the release GitHub Actions workflow to make releases safer by requiring a manual publish step and preventing “official” version tags from being cut from non-master history.
Changes:
- Create GitHub Releases as drafts (
draft: true) so a human must publish after reviewing artifacts. - Add a validation step that checks official release tags (
vX.Y.Z, non-prerelease) are reachable fromorigin/master. - Update the workflow summary messaging to reflect draft releases and add an explicit “action required” note.
.github/workflows/release.yml
Outdated
Comment on lines
+156
to
+157
| # Fetch latest master to ensure our ref is up to date | ||
| git fetch origin master --depth=100 2>/dev/null || true |
There was a problem hiding this comment.
git fetch origin master --depth=100 2>/dev/null || true can make the ancestry check unreliable (shallow fetch may not include the tagged commit if it’s older than 100 commits) and also masks fetch failures, which can lead to confusing “tag is NOT on master” errors. Fetch master without a depth limit and let fetch errors fail the step (or handle them explicitly with a clear error message) so git merge-base --is-ancestor is deterministic.
Suggested change
| # Fetch latest master to ensure our ref is up to date | |
| git fetch origin master --depth=100 2>/dev/null || true | |
| # Fetch latest master to ensure our ref is up to date (full history, fail on error) | |
| if ! git fetch origin master; then | |
| echo "❌ Failed to fetch origin/master. Cannot validate that $TAG_NAME is on the master branch." | |
| exit 1 | |
| fi |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
.github/workflows/release.yml (1)
145-168: Move the validation step before the expensive environment setup for fail-fast behavior.The step only requires
git(already available after checkout), but currently it runs after NDK setup, JDK setup,apt-gettool installation, and cache restoration — all of which take several minutes. If validation fails (e.g., a tag pushed from the wrong branch), those minutes are wasted.Move the step to immediately after the "Extract tag version" step (currently ending at line 143).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release.yml around lines 145 - 168, Move the "Validate tag is on master branch (official releases only)" step so it runs immediately after the "Extract tag version" step to fail fast; specifically, cut the entire step block that computes TAG_NAME, resolves TAG_COMMIT with git rev-parse "${TAG_NAME}^{commit}", fetches origin/master, and checks merge-base --is-ancestor, and paste it directly after the step that ends with "Extract tag version" (so it runs before NDK/JDK setup, apt-get/tool installs, and cache restore). Ensure the step's if condition (steps.tag_version.outputs.is_prerelease == 'false') and its exit 1 behavior remain unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/release.yml:
- Around line 539-542: The workflow creates releases as draft, so make_latest
(make_latest: ${{ steps.tag_version.outputs.is_prerelease != 'true' }}) is
ignored; update the release summary action-required note referenced around the
summary step to explicitly tell operators they must manually check "Set as the
latest release" when publishing drafts, and/or add a new follow-up workflow
triggered on release: published that uses the Releases API to set the published
non-prerelease release as latest (use the tag from steps.tag_version.outputs or
release payload) so the "latest" designation is applied automatically after a
draft is published.
- Around line 619-622: The current step-summary link uses releases/tag/$TAG_NAME
which 404s for non-push users while the release is a draft; change the URL
written to GITHUB_STEP_SUMMARY to point to the repository's releases management
page (use ${{ github.server_url }}/${{ github.repository }}/releases) instead of
releases/tag/$TAG_NAME so the draft is visible to authorized users, and keep the
existing IS_PUBLISH conditional and messages using GITHUB_STEP_SUMMARY and
TAG_NAME as needed.
- Around line 153-160: The script currently assigns TAG_COMMIT via git rev-parse
without checking for failure and fetches origin/master with --depth=100 which
can create shallow markers; change the logic so after running git rev-parse
"${TAG_NAME}^{commit}" you check its exit status and/or ensure TAG_COMMIT is
non-empty and fail with a clear error like "tag not found" instead of
continuing, remove the --depth=100 option from the git fetch origin master call
so it does not introduce shallow boundaries, and ensure the git merge-base
--is-ancestor check is only run when TAG_COMMIT is valid (avoid suppressing and
hiding stderr for these git commands so errors surface).
---
Nitpick comments:
In @.github/workflows/release.yml:
- Around line 145-168: Move the "Validate tag is on master branch (official
releases only)" step so it runs immediately after the "Extract tag version" step
to fail fast; specifically, cut the entire step block that computes TAG_NAME,
resolves TAG_COMMIT with git rev-parse "${TAG_NAME}^{commit}", fetches
origin/master, and checks merge-base --is-ancestor, and paste it directly after
the step that ends with "Extract tag version" (so it runs before NDK/JDK setup,
apt-get/tool installs, and cache restore). Ensure the step's if condition
(steps.tag_version.outputs.is_prerelease == 'false') and its exit 1 behavior
remain unchanged.
… r29 - build.gradle: ndkVersion 26.3.11579264 → 27.2.12479018 (r27c) - release.yml: ndk-version r26d → r27c (committed separately) - CI matrices (ubuntu/windows/macos): replace r26d+r27c with r27c+r29 - r27c: current release NDK, ensures production quality - r29: latest stable NDK, detects forward compatibility issues early - macos-build.yml: update version mapping table r26d entry → r29 (29.0.14206865)
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/release.yml:
- Around line 413-414: The workflow currently does a direct git push ("git push
origin master") after "git commit -m \"Publish artifacts ${TAG_NAME}\"", which
can fail with a non-fast-forward and leave releases and artifacts inconsistent;
modify the step that runs git commit and git push to perform a guarded push:
fetch origin, attempt to rebase/merge upstream changes (or abort and retry), and
retry the push a few times (e.g., loop with git fetch origin && git rebase
origin/master && git push origin master) with clear logging; alternatively, if
you prefer not to implement retries, catch the push failure and emit a clear
error message instructing the operator to re-run the Maven sync and re-push
artifacts (include TAG_NAME in the message) and exit non-zero so the operator
can recover manually—apply this change around the commands that currently run
git commit and git push in the release.yml step that has set -euo pipefail
enabled.
---
Duplicate comments:
In @.github/workflows/release.yml:
- Around line 599-602: The step summary currently writes a permalink to
releases/tag/$TAG_NAME which 404s for drafts; update the echo that references
"${{ github.server_url }}/${{ github.repository }}/releases/tag/$TAG_NAME" to
point to the releases management page instead (e.g. "${{ github.server_url
}}/${{ github.repository }}/releases") while still showing the draft tag name
(use TAG_NAME or $TAG_NAME) in the message; modify the line that writes to
GITHUB_STEP_SUMMARY and keep the surrounding IS_PUBLISH conditional and
GITHUB_STEP_SUMMARY echoes unchanged.
- Around line 153-168: The TAG_COMMIT lookup and shallow fetch are fragile:
ensure TAG_COMMIT from git rev-parse is validated and fail fast if the tag does
not exist (check the exit status or emptiness of TAG_COMMIT after running git
rev-parse and print a clear "tag not found" error and exit 1), and avoid the
shallow-boundary problem by removing the fixed --depth=100 on the git fetch (use
a full fetch/unshallow or plain git fetch origin master so the repo has the full
history before running git merge-base). Locate the TAG_COMMIT assignment and the
git fetch origin master --depth=100 line in the block and replace with guarded
rev-parse logic plus a non-shallow fetch strategy so git merge-base behaves
correctly.
- Around line 519-522: The workflow sets draft: true unconditionally so
make_latest (make_latest: ${{ steps.tag_version.outputs.is_prerelease != 'true'
}}) is ignored while the release is a draft; change the draft setting to be
conditional (e.g., draft: ${{ steps.tag_version.outputs.is_prerelease == 'true'
}}) so non-prereleases are created published and GitHub will evaluate
make_latest, and update the action-required note to explain that drafts do not
apply make_latest and when manual intervention is needed; target the draft,
make_latest and steps.tag_version.outputs.is_prerelease symbols in the release
job.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
.github/workflows/windows-build.yml (1)
23-23: Windows PR matrix skips r29 — r29 regressions on Windows won't block merges.The PR path tests only r27c. A Windows-specific build failure with r29 (e.g., MSVC/Clang path differences) would only surface after the PR is merged and the
pushmatrix fires. Consider adding one r29 entry to the Windows PR matrix (e.g., mirroring the r29+cmake+no-ffmpeg+4kb entry) to get earlier signal, even if it means a slightly longer PR gate.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/windows-build.yml at line 23, The PR matrix currently only includes NDK r27c for Windows runs in the conditional include expression; add a single r29 entry to the JSON array used in the include (mirror the existing r29+cmake+no-ffmpeg+4kb combination) so the Windows PR path will also run an r29+cmake+no-ffmpeg+4kb job—update the JSON string used in the include expression accordingly to insert that object into the array..github/workflows/macos-build.yml (1)
23-23: Samendk-buildpost-merge coverage gap asubuntu-build.yml.The macOS PR matrix exercises r29+ndk-build, but every entry in the non-PR (master push) matrix uses cmake.
ndk-buildis never validated after a merge. Adding a single ndk-build entry to the non-PR matrix (e.g., r29+ndk-build+no-ffmpeg+4kb) would close this gap.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/macos-build.yml at line 23, The non-PR JSON matrix in the include expression (the value of include:) lacks any ndk-build entries, so ndk-build never runs on pushes; add a single object to that non-PR array with os:"macos-latest", os-name:"macOS", ndk:"r29", build-system:"ndk-build", ffmpeg:"no-ffmpeg", page-size:"4kb" so post-merge builds validate ndk-build (leave the PR conditional branch unchanged)..github/workflows/ubuntu-build.yml (1)
23-23:ndk-buildis absent from the master-push matrix — post-merge regressions go undetected.The PR matrix covers
ndk-build(r27c+ndk-build+no-ffmpeg+4kb), but the master-push matrix contains onlycmakevariants. Anyndk-buildregression introduced between two PRs (e.g., a direct commit to master) won't be caught until the next PR that happens to trigger it. The same gap exists inmacos-build.yml.Consider adding at least one
ndk-buildentry to the non-PR matrix (e.g., r27c+ndk-build+no-ffmpeg+4kb on Ubuntu) so the build path is continuously validated on master.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/ubuntu-build.yml at line 23, The non-PR matrix generation line using include: ${{ fromJson(...) }} in ubuntu-build.yml lacks any ndk-build entries, so add at least one ndk-build object (e.g., {"os":"ubuntu-latest","os-name":"Ubuntu","ndk":"r27c","build-system":"ndk-build","ffmpeg":"no-ffmpeg","page-size":"4kb"}) into the JSON array used when github.event_name != 'pull_request' so master-push runs validate ndk-build; locate the include: ${{ fromJson(...) }} expression and insert that ndk-build entry into the second JSON list (the non-PR branch).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@build.gradle`:
- Line 44: The project currently pins ndkVersion to "27.2.12479018" in
build.gradle which can cause CI failures when runners provide r29; either update
the ndkVersion value in build.gradle from "27.2.12479018" to "29.0.14206865"
(the CI primary target) or modify the CI NDK setup step to install both r27c and
r29 so the declared ndkVersion path exists; locate the ndkVersion declaration in
build.gradle and apply one of these two fixes so AGP can find the expected NDK.
---
Nitpick comments:
In @.github/workflows/macos-build.yml:
- Line 23: The non-PR JSON matrix in the include expression (the value of
include:) lacks any ndk-build entries, so ndk-build never runs on pushes; add a
single object to that non-PR array with os:"macos-latest", os-name:"macOS",
ndk:"r29", build-system:"ndk-build", ffmpeg:"no-ffmpeg", page-size:"4kb" so
post-merge builds validate ndk-build (leave the PR conditional branch
unchanged).
In @.github/workflows/ubuntu-build.yml:
- Line 23: The non-PR matrix generation line using include: ${{ fromJson(...) }}
in ubuntu-build.yml lacks any ndk-build entries, so add at least one ndk-build
object (e.g.,
{"os":"ubuntu-latest","os-name":"Ubuntu","ndk":"r27c","build-system":"ndk-build","ffmpeg":"no-ffmpeg","page-size":"4kb"})
into the JSON array used when github.event_name != 'pull_request' so master-push
runs validate ndk-build; locate the include: ${{ fromJson(...) }} expression and
insert that ndk-build entry into the second JSON list (the non-PR branch).
In @.github/workflows/windows-build.yml:
- Line 23: The PR matrix currently only includes NDK r27c for Windows runs in
the conditional include expression; add a single r29 entry to the JSON array
used in the include (mirror the existing r29+cmake+no-ffmpeg+4kb combination) so
the Windows PR path will also run an r29+cmake+no-ffmpeg+4kb job—update the JSON
string used in the include expression accordingly to insert that object into the
array.
| applicationId : "org.wysaid.cgeDemo", | ||
| appcompatX : "1.2.0", | ||
| ndkVersion : "26.3.11579264", | ||
| ndkVersion : "27.2.12479018", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Find build.gradle and CI workflow files
fd -t f "build\.gradle" -x cat -n {} \;Repository: wysaid/android-gpuimage-plus
Length of output: 13956
🏁 Script executed:
#!/bin/bash
# Find GitHub Actions workflow files
fd -t f "\.(yml|yaml)$" ".github/workflows/" -x cat -n {} \;Repository: wysaid/android-gpuimage-plus
Length of output: 47969
🏁 Script executed:
#!/bin/bash
# Search for NDK version references in the codebase
rg "27\.2\.12479018|29\.0\.14206865" --include="*.gradle" --include="*.yml" --include="*.yaml"Repository: wysaid/android-gpuimage-plus
Length of output: 513
Update ndkVersion to match the CI matrix's primary target NDK version, or ensure both r27c and r29 are available during builds.
The build.gradle declares ndkVersion "27.2.12479018" (r27c), but the CI workflows—particularly on ubuntu-latest and windows-latest—test against both r27c and r29. When a job runs with r29 installed via nttld/setup-ndk and build-system: cmake is enabled, AGP searches for the declared r27c version in $ANDROID_SDK_ROOT/ndk/27.2.12479018/. If r27c is not present, the build fails.
Options:
- Update
ndkVersionto"29.0.14206865"once r29 is validated as the stable target - Install both r27c and r29 simultaneously on runners by customizing the NDK setup step
- Modify CI matrix to use ndk-build (which may not respect ndkVersion) for one of the versions
CI matrix evidence
Ubuntu PR jobs: includes {"ndk":"r29","build-system":"cmake",...} and {"ndk":"r27c","build-system":"ndk-build",...}
Windows PR jobs: includes {"ndk":"r27c","build-system":"cmake",...} only
macOS PR jobs: includes {"ndk":"r29","build-system":"cmake",...} only
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@build.gradle` at line 44, The project currently pins ndkVersion to
"27.2.12479018" in build.gradle which can cause CI failures when runners provide
r29; either update the ndkVersion value in build.gradle from "27.2.12479018" to
"29.0.14206865" (the CI primary target) or modify the CI NDK setup step to
install both r27c and r29 so the declared ndkVersion path exists; locate the
ndkVersion declaration in build.gradle and apply one of these two fixes so AGP
can find the expected NDK.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/release.yml:
- Around line 564-567: Inside the IS_PUBLISH == 'true' branch the nested if
checking IS_MANUAL is dead because IS_MANUAL is always 'false' there; remove the
inner conditional and unconditionally append the trigger line (i.e., always echo
"**Trigger**: Tag push" into $GITHUB_STEP_SUMMARY when inside the IS_PUBLISH
branch) — update the block containing the lines that write VERSION and the
conditional on IS_MANUAL to instead always write the "Trigger: Tag push"
message.
---
Duplicate comments:
In @.github/workflows/release.yml:
- Around line 400-401: The workflow step uses a plain `git push origin master`
which can fail with non-fast-forward if concurrent pushes occurred; update the
release job to guard the push with a retry loop and safe semantics (e.g.,
attempt `git push --force-with-lease` or retry `git push origin master` up to N
times with short backoff) so transient push rejections don't abort the step;
modify the block around the `git commit -m "Publish artifacts ${TAG_NAME}"` /
`git push origin master` commands to retry pushes and surface a clear error
message after exhausting retries.
- Around line 587-589: The release summary currently prints a draft-specific URL
using "releases/tag/$TAG_NAME" which returns 404 for users without push access;
update the echo that writes to GITHUB_STEP_SUMMARY to use the repository
releases management page (i.e., ".../${{ github.repository }}/releases") instead
of the tag-specific path so authorized operators can open the draft, keeping the
existing variables (GITHUB_STEP_SUMMARY and TAG_NAME) but replacing the path
segment "releases/tag/$TAG_NAME" with "releases".
- Around line 140-144: Guard the tag resolution and avoid introducing a shallow
fetch: after running git rev-parse "${TAG_NAME}^{commit}" check its exit status
/ that TAG_COMMIT is non-empty and if it failed log a clear error (include
TAG_NAME) and exit non‑zero instead of proceeding; and replace the shallow fetch
command git fetch origin master --depth=100 with a non‑shallow fetch (e.g.,
remove the --depth flag or use a full fetch like git fetch origin master
--no-tags --prune / git fetch --unshallow when appropriate) so the repository
retains full history for correct git merge-base behavior.
- Around line 506-509: The workflow sets make_latest unconditionally which
GitHub ignores for draft releases; update the release job so make_latest is only
true when the release is not a draft and not a prerelease (combine the existing
prerelease check with the draft flag), e.g. change the make_latest line to a
logical expression that also checks the draft value used in this job (so
make_latest: ${{ steps.tag_version.outputs.is_prerelease != 'true' && draft !=
'true' }} or equivalent expression that references your workflow's draft
source), or alternately ensure draft is false for runs that should set latest;
adjust the make_latest, draft and prerelease settings together (symbols:
make_latest, draft, prerelease, steps.tag_version.outputs.is_prerelease) so
make_latest is never relied on for draft releases.
There was a problem hiding this comment.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In @.github/workflows/release.yml:
- Around line 586-589: The step summary currently links to the tag URL that 404s
for non-push users; update the summary generation to point to the repository
releases management page instead of releases/tag/$TAG_NAME so the draft is
discoverable by authorized operators. Locate the lines writing to
GITHUB_STEP_SUMMARY that reference TAG_NAME and replace the tag-specific URL
`${{ github.server_url }}/${{ github.repository }}/releases/tag/$TAG_NAME` with
the repository releases page `${{ github.server_url }}/${{ github.repository
}}/releases` (you can still include TAG_NAME in the text for context), and keep
the existing human-action message unchanged.
- Around line 132-155: Guard the git rev-parse and remove the shallow fetch:
ensure TAG_COMMIT is computed with git rev-parse "${TAG_NAME}^{commit}" and
immediately check its exit status (or test for non-empty TAG_COMMIT); if
rev-parse fails, print a clear error mentioning the tag and exit non-zero
instead of proceeding to git merge-base; replace the shallow fetch command git
fetch origin master --depth=100 2>/dev/null || true with a full fetch (no
--depth) and avoid swallowing stderr so failures are visible; reference the
TAG_COMMIT variable and the commands git rev-parse, git fetch origin master, and
git merge-base --is-ancestor when making these changes.
- Around line 347-407: The push to the artifact repo can race and fail
non-fast-forward at git push origin master; wrap the push in a retry guard that,
on failure, fetches and rebases the remote (git fetch origin && git rebase
origin/master or git pull --rebase origin master), re-applies the WORKDIR
changes, retries the commit/push up to a small max attempts with exponential
backoff, and on persistent failure aborts the job with a descriptive error and
no artifact_commit_url output; apply this logic around the git commit / git push
origin master sequence (use the existing WORKDIR, git clone, rsync, genSites.sh,
COMMIT_SHA/COMMIT_URL symbols to locate the code) so the workflow either
reliably updates the maven repo or fails cleanly for manual recovery.
- Around line 561-567: The inner conditional is dead because IS_MANUAL is set to
"false" earlier; update the release summary logic so the "Trigger: Tag push"
line is emitted when the tag-push/publish path runs by replacing the check
against IS_MANUAL with a check against IS_PUBLISH (or simply always echo the
trigger inside the IS_PUBLISH branch); locate the block writing to
GITHUB_STEP_SUMMARY that references TAG_NAME and VERSION and change the if [
"$IS_MANUAL" = "true" ] test to reference IS_PUBLISH (or remove the conditional)
so the trigger line is actually written for the tag-push path.
wysaid
changed the title
…rse and remove --depth=100 from master fetch\n (shallow boundary caused false-negative ancestor checks)\n- Add retry loop (up to 3 attempts) for artifact repo push\n (handles transient non-fast-forward on concurrent pushes)\n- Remove dead IS_MANUAL conditional inside IS_PUBLISH branch\n (IS_MANUAL is always false when IS_PUBLISH is true)\n- Fix draft release URL in step summary (was releases/tag/$TAG_NAME\n which 404s for non-push users; now points to releases management page)"
Owner
Author
|
@Auggie review |
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
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.
Summary
Five improvements to the release workflow, CI matrix, and build configuration:
1. GitHub Releases are always created as Draft first
The
Create GitHub Releasestep now setsdraft: true. After the workflow completes, a human must review artifacts on the GitHub Releases page and click Publish release to make it public.This prevents accidental publication of broken or unreviewed releases.
2. Official release tags must point to a commit on master
A new step "Validate tag is on master branch (official releases only)" is inserted before version validation.
is_prerelease == false), i.e. tags matchingv*.*.*exactly.-beta,-alpha,-rc) are exempt from this check.git merge-base --is-ancestorto verify the tag's commit is reachable fromorigin/master.3. Maven artifacts published via direct commit instead of PR
The artifact publishing step now pushes a commit directly to the Maven artifact repository (
origin/master) instead of creating a pull request.artifact_commit_url(direct commit URL) instead of a PR URL.4. Upgrade default NDK from r26d to r27c; add r29 to CI matrix
build.gradle:ext.android.ndkVersionbumped from26.3.11579264(r26d) to27.2.12479018(r27c).5. Manual trigger always runs as dry-run; remove
publish_releaseinputworkflow_dispatchtrigger no longer has apublish_releaseboolean input.IS_PUBLISH=false(dry-run), preventing accidental artifact publication from manual triggers.6. Fail hard when
ARTIFACT_REPO_TOKENis missing during releaseA new guard step checks for the presence of
ARTIFACT_REPO_TOKENearly in the release job. If the secret is absent, the workflow exits immediately with a clear error message instead of silently failing later during the artifact push.Changed Files
.github/workflows/release.yml.github/workflows/macos-build.yml.github/workflows/ubuntu-build.yml.github/workflows/windows-build.ymlbuild.gradlendkVersionr26d → r27cHow to verify
v*.*.*tag from a non-master branch → workflow fails at master validation step.v*.*.*-beta1tag from any branch → master validation step is skipped.IS_PUBLISHis alwaysfalse; no artifacts are published.ARTIFACT_REPO_TOKEN→ workflow fails immediately with a clear error.Summary by CodeRabbit