ci: create build-only action for testing in forks

[0xbrayo]

Important

Add build-only.yml workflow for building aw-server-rust and Android APK/AAB with caching and artifact upload.

• Workflow Setup:
  • New workflow build-only.yml for building aw-server-rust and Android APK/AAB.
  • Triggered on master branch pushes, pull requests, and tags starting with 'v'.
• Jobs:
  • build-rust: Builds aw-server-rust on macOS, caches JNI libs and Rust cargo builds.
  • get-versionCode: Retrieves version code from mobile/build.gradle.
  • build-apk: Builds Android APK/AAB, sets up environments, caches JNI libs.
• Caching and Environment:
  • Caches JNI libraries and Rust cargo builds.
  • Sets up Android SDK, NDK, Rust, and Java environments.
• Artifact Handling:
  • Uploads built APK/AAB artifacts using actions/upload-artifact@v4.

^{This description was created by for 10efdf8. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 10efdf8 in 2 minutes and 26 seconds. Click for details.

• Reviewed 216 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 7 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. .github/workflows/build-only.yml:162

• Draft comment:
  Verify that 'actions/cache/restore@v3' is a valid action. The standard caching action is 'actions/cache@v3' which handles both restoring and saving. Ensure the custom restore usage is intentional.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

2. .github/workflows/build-only.yml:190

• Draft comment:
  The condition 'if: env.KEY_ANDROID_JKS != null' may not work as expected if KEY_ANDROID_JKS isn't set. Consider checking 'if: secrets.KEY_ANDROID_JKS' or verifying the variable is non-empty.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% In GitHub Actions, checking env.KEY_ANDROID_JKS != null when the env variable is set from a secret in the same step might indeed be problematic. The if condition is evaluated before the step runs, so env.KEY_ANDROID_JKS wouldn't exist yet at evaluation time. The comment suggests checking secrets.KEY_ANDROID_JKS directly instead, which would be evaluated at the right time. However, I need to be careful - the comment is making a suggestion about behavior that might work differently than expected. The current code might actually work fine if GitHub Actions handles this case. Without being 100% certain this is a bug, and given the rule about not making speculative comments, I should be cautious. The comment does provide a concrete code change suggestion though. I might be wrong about how GitHub Actions evaluates these conditions. The current code might work perfectly fine if env variables set in the same step's env block are available to the if condition. I don't have definitive proof that this is broken, and the comment is somewhat speculative ("may not work as expected"). The comment's own language ("may not work") indicates uncertainty. According to the rules, I should not keep speculative comments. If this were a definite bug, the comment would state it more definitively. The fact that it says "may not work" and "consider" suggests this is not a clear-cut issue with strong evidence. This comment is speculative in nature ("may not work as expected", "consider checking"). Without strong evidence that the current code is definitely broken, and given the speculative language used, this comment should be deleted per the rule against speculative comments.

3. .github/workflows/build-only.yml:102

• Draft comment:
  Consider using a consistent version of 'actions/checkout' (e.g. v3) across all jobs for uniformity.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

4. .github/workflows/build-only.yml:107

• Draft comment:
  The sed command for extracting versionCode from mobile/build.gradle assumes a specific format. A more robust parsing method or error handling might help if the file format changes.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment is suggesting a potential improvement to make the code more robust. However, looking at the rules: "Do NOT make speculative comments, such as 'If X, then Y is an issue', Only comment if it is definitely an issue." This comment says "might help if the file format changes" - this is speculative. It's not pointing out a current bug or definite issue. The comment is also somewhat vague - it doesn't provide a specific actionable suggestion, just says "a more robust parsing method or error handling might help." Without seeing the actual mobile/build.gradle file to confirm there's a problem, this seems like a speculative suggestion about future-proofing rather than fixing a current issue. The sed command could legitimately be fragile if the gradle file format varies. The comment might be pointing out a real robustness issue that could cause CI failures. Without seeing the actual gradle file, I can't be certain this is purely speculative. While the sed command might be fragile, the comment doesn't demonstrate that there's an actual problem with the current code - it's a "might help if" suggestion. The rules explicitly state not to make speculative comments. If the parsing were definitely broken or there was evidence of a format issue, that would be different. This is more of a general code quality suggestion without strong evidence of a problem. This comment should be deleted. It's speculative ("might help if the file format changes") rather than pointing to a definite issue. It doesn't provide specific actionable guidance, and there's no evidence that the current parsing is actually broken or problematic.

5. .github/workflows/build-only.yml:175

• Draft comment:
  Using 'tail -c +2' to strip the leading 'v' from the tag is clever but may be brittle. Consider a more explicit substring extraction to handle edge cases.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

6. .github/workflows/build-only.yml:92

• Draft comment:
  Typo: 'seperate' should be 'separate'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This is a spelling/typo correction in a comment. While it is technically correct (seperate should be separate), I need to consider the rules: 1) The comment is about a change (new file added), 2) It's not asking for confirmation or explanation, 3) It's not speculative, 4) However, the rules state "Do NOT comment unless there is clearly a code change required" and "Do NOT make comments that are obvious or unimportant." A typo in a comment is not a code change - it's documentation/comment text. This doesn't affect functionality at all. The rules emphasize only commenting when there's a clear code change required, and fixing a typo in a comment is arguably not a required code change - it's a minor documentation improvement. While the typo is real and the correction is valid, one could argue that fixing spelling in comments does improve code quality and readability. Comments are part of the codebase and maintaining proper spelling could be considered good practice. The comment is actionable and clear. However, the rules explicitly state not to make comments that are "obvious or unimportant" and to only comment when "there is clearly a code change required." A spelling error in a comment doesn't affect functionality, and while it's nice to fix, it's not a required code change. The rules prioritize avoiding low-value comments. This comment should be deleted. While the typo is real, fixing spelling in comments is not a required code change and falls under "obvious or unimportant" comments that should be avoided per the rules.

7. .github/workflows/build-only.yml:94

• Draft comment:
  Typographical error: duplicate word 'and and'; remove one occurrence.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 30% vs. threshold = 50% This is a straightforward typo fix in a comment. The comment is correct - there is indeed "and and" on line 94. However, I need to consider the rules: 1) This is just a comment/documentation fix, not a code change that affects functionality. 2) The rules say "Do NOT comment unless there is clearly a code change required" - a typo in a comment doesn't require a code change for functionality. 3) The rules also say "Do NOT make comments that are obvious or unimportant" - this is a minor typo in a comment. 4) However, the rules also say "Comments that suggest code quality refactors are good! But only if they are actionable and clear" - this is actionable and clear. But is fixing a typo in a comment really a "code quality refactor"? It's more of a documentation quality issue. Given the emphasis on not making obvious or unimportant comments, and that this doesn't affect functionality, I lean toward deleting this comment. While the typo is real and the fix is correct, fixing typos in comments is generally considered low-priority and might fall under "obvious or unimportant" comments. The automated tool might be being overly pedantic about documentation quality when the focus should be on functional code issues. Although the typo fix is minor, it is actionable, clear, and improves code quality (even if just documentation quality). The fix is trivial to apply and makes the comment more professional. However, the rules emphasize not making obvious or unimportant comments, and a typo in a comment is arguably unimportant from a functionality perspective. This comment identifies a real typo but falls into the category of "obvious or unimportant" comments that the rules say to avoid. Since it doesn't affect functionality and is just a minor documentation issue, it should be deleted.

Workflow ID: wflow_4v8kegW3IaYeeIAl

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}