Repository navigation
ci: a release of its own for every 2.xx version (#157) - #158
Conversation
… changes since the previous one (#157) Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
|
/review |
Code Review by Qodo
1. Incomplete releases can appear successful
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
…meanwhile by another build is fine Co-Authored-By: Claude <noreply@anthropic.com>
|
Qodo → fix: 1. if |
|
/review |
Both reported issues appear addressed:
The examples you checked ( |
|
Code review by qodo was updated up to the latest commit ee30456 |
… release without its APK gets it uploaded, all v2 tags count for the notes Co-Authored-By: Claude <noreply@anthropic.com>
|
Qodo round 2 → fix: 1. Telegram: real — reading both Gradle paths would fail under |
|
/review |
Based on the updated diff, the changes address the remaining open findings:
The previously resolved findings remain addressed as well. I can’t independently rerun the review from this comment, but these changes align with the recommended fixes. |
|
Code review by qodo was updated up to the latest commit ba0b088 |
… APK; a failed release lookup fails the step Co-Authored-By: Claude <noreply@anthropic.com>
|
Qodo round 3 → fix: the missing-APK repair uploads only when the release tag points to the commit just built (else a warning, nothing attached); the release list is fetched on its own, so a failed request fails the step instead of producing first-release notes. |
|
/review |
Confirmed. The current diff addresses:
Both fixes are reflected in the latest workflow changes. |
| echo "::warning::$TAG has no $APK and points to ${TAGGED:0:7}, not this build" | ||
| fi |
There was a problem hiding this comment.
1. Incomplete releases can appear successful 🐞 Bug ≡ Correctness
repair_apk returns success after only printing a warning when the release tag points to a different commit. If an existing release lacks its APK and the current build is not of its tagged commit, the step exits successfully without uploading the missing asset.
Agent Prompt
## Issue description
An existing release without its APK is treated as successfully published when the current build cannot safely repair it.
## Fix Focus Areas
- .github/workflows/build.yml[140-155]
- .github/workflows/build.yml[169-175]
## Recommended Fix
Keep the commit check that prevents uploading an APK from the wrong build, but return a nonzero status when it prevents repair. Ensure both callers fail unless the release has its APK.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| - name: Versioned release | ||
| if: github.ref_name == 'v2' |
There was a problem hiding this comment.
4. A failed latest upload skips versioning 🐞 Bug ☼ Reliability
Versioned release follows the Upload action with an if condition that does not override the default success requirement. If publishing latest fails, the job skips versioned publication even though the signed APK has already been built.
Agent Prompt
## Issue description
Failure of the preceding latest-release upload prevents an otherwise built APK from receiving its versioned release.
## Fix Focus Areas
- .github/workflows/build.yml[114-130]
## Recommended Fix
Make versioned publication independent of the latest upload, for example by giving it an appropriate status-aware condition or moving both publications into independent jobs.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| if ! gh release create "$TAG" "$APK" --target "$(git rev-parse HEAD)" \ | ||
| --title "OpenIPC Decoder ${VER}" --latest=false "${NOTES[@]}"; then |
There was a problem hiding this comment.
5. Pre-existing tags can get the wrong apk 🐞 Bug ≡ Correctness
gh release create supplies the built commit through --target but does not check whether the version tag already exists. If that tag exists without a release and points to another commit, release creation uses the existing tag while attaching the current build's APK; the tag-commit check applies only to missing-asset repair.
Agent Prompt
## Issue description
A version tag that predates its release can point to a different commit from the APK attached during release creation.
## Fix Focus Areas
- .github/workflows/build.yml[149-170]
## Recommended Fix
Before creating a release, check whether its tag exists. If it does, require that it resolves to the built commit before attaching the APK; otherwise fail without publishing a mismatched asset.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
|
Code review by qodo was updated up to the latest commit 9956b17 |
|
Qodo round 4 (9956b17) — declined, with reasons:
|
Understood. The remaining findings are intentionally declined based on the workflow’s operational policy:
All other findings are resolved, and the PR is merged. |
…meanwhile by another build is fine Co-Authored-By: Claude <noreply@anthropic.com>
… release without its APK gets it uploaded, all v2 tags count for the notes Co-Authored-By: Claude <noreply@anthropic.com>
… APK; a failed release lookup fails the step Co-Authored-By: Claude <noreply@anthropic.com>
ci: a release of its own for every 2.xx version (#157)
1 participant
Closes #157.
versionNamefromandroid/app/build.gradle; ifv<versionName>has no release yet, creates it at the built commit — title OpenIPC Decoder 2.01, assetdecoder-v2-2.01.apk, notes generated by GitHub from the merged PRs since the previousv2.*release (the first one gets a short note instead). Not marked Latest.latestis updated, as before.Version: …(also forbasic, whose Gradle files are at the top level).After merging, the v2 build of this merge creates v2.01 (current
versionName), so the first versioned release is the build now on both lab boxes plus this CI change.