Fix part of #5508: Limit APK/AAB Difference analysis reports in the PR Comment Thread

[Rd4dev]

Explanation

Fixes #5533
Fixes part of #5508

This PR includes

1. Updates the workflow to use v4 of the upload-artifact

2. Steps to locate the previous stats.yml workflow run, download its build artifact, and compare it with the current build log. If changes are detected, a comment will be uploaded to help minimize comment thread overload.

The implementation:

• Download the previous build log artifact (if available).
• Run the script.
• Compare the current generated build log with the previous build log artifact:
  • if no differences are found -> skip commenting.
  • if differences are found -> comment the current generated build log
  • if no previous artifact is found -> comment the current generated build log
    • This occurs in 2 instances:
      • 1. It's the first run of the PR.
      • 2. An error occurred during the previous stat check (since the previous build is from the second-to-last run ID).
• Upload the current build log as an artifact (for the next stat run).
• Comment/skip the stat report based on the comparison result.

Tested with a cloned PR

(with stats.yml implementation on develop)

Tested PR: Rd4dev/Oppia-Android-Fork-from-Fork#40

Reference for proof of implementation:

• should comment on initial run | comment | stack trace
• shouldn't comment when no change | reference1 | reference2
• should comment on change | comment | reference
• comment on previous build fail (replicated!) | comment | reference

Essential Checklist

• The PR title and explanation each start with "Fix #bugnum: " (If this PR fixes part of an issue, prefix the title with "Fix part of #bugnum: ...".)
• Any changes to scripts/assets files have their rationale included in the PR explanation.
• The PR follows the style guide.
• The PR does not contain any unnecessary code changes from Android Studio (reference).
• The PR is made from a branch that's not called "develop" and is up-to-date with "develop".
• The PR is assigned to the appropriate reviewers (reference).

[Rd4dev]

@BenHenning, would this approach work in limiting the report thread in the right way? Can you PTAL?

Also, Noticing that previous stat runs sometimes fail [workflow run], if the artifacts aren’t uploaded, the next check would treat it as if no previous log was found, potentially leading to duplicated comments.

[github-actions]

Coverage Report

Results

Coverage Analysis: SKIP ⏭️

This PR did not introduce any changes to Kotlin source or test files.

To learn more, visit the Oppia Android Code Coverage wiki page

[github-actions]

Coverage Report

Results

Coverage Analysis: SKIP ⏭️

This PR did not introduce any changes to Kotlin source or test files.

To learn more, visit the Oppia Android Code Coverage wiki page

[BenHenning]

Ah this is a really clever solution--great idea! Thanks for creating this @Rd4dev and for the thorough testing that you included in the PR! I have no additional suggestions, this LGTM as-is. :)

[BenHenning]

Given how much the build stats workflow has been 'spamming' PRs (and keeping them from being auto-closed from Oppiabot stale detection), enabling auto-merge to get this in soon.

[oppiabot]

Unassigning @BenHenning since they have already approved the PR.

[oppiabot]

Assigning @adhiamboperes for code owner reviews. Thanks!

[github-actions]

Coverage Report

Results

Coverage Analysis: SKIP ⏭️

This PR did not introduce any changes to Kotlin source or test files.

To learn more, visit the Oppia Android Code Coverage wiki page

[Rd4dev]

Thank you so much @BenHenning. I’d like to clarify the failure cases with the stats reports, as they seem to fail often. Is this likely a flake, or can it be fixed? I’m concerned it might lead to duplicated comments with previous failure stats.

The artifact approach seemed straightforward and clean, but wondering if it’s unreliable, would checking actual comments via the GitHub API to compare changes be a viable alternative? (I haven’t tried this yet...) but just like to know the best approach.

[BenHenning]

Thank you so much @BenHenning. I’d like to clarify the failure cases with the stats reports, as they seem to fail often. Is this likely a flake, or can it be fixed? I’m concerned it might lead to duplicated comments with previous failure stats.

The artifact approach seemed straightforward and clean, but wondering if it’s unreliable, would checking actual comments via the GitHub API to compare changes be a viable alternative? (I haven’t tried this yet...) but just like to know the best approach.

What failures are you observing? It seems that the stats workflow has been fairly reliable, but admittedly I haven't actually analyzed it in detail.

Separately, I notice that CI workflows are failing due to us using a very old version of upload artifact in existing workflows. Could you maybe update those in this PR? Since we're going to merge this soon, it would be convenient to go ahead and fix that here so that we can unblock the rest of the team (it seems something changed on GitHub's side that's presumably going to cause all PRs to fail).

[Rd4dev]

Updated this PR to use v4 upload-artifact.

What failures are you observing?

Though the last couple of stats.yml failures are due to the deprecated v2 artifact, the previous checks to them too seem to fail in most cases (with ProGuard issues, I guess).

Actions/stats check:

[Actions Tab]

Stat runs:

Failure at build - feature branch step: (Run # 154)

[Failure stack trace # 154]

The same PR passing checks (Run # 155)

[Passing stack trace # 155]

[github-actions]

Coverage Report

Results

Coverage Analysis: SKIP ⏭️

This PR did not introduce any changes to Kotlin source or test files.

To learn more, visit the Oppia Android Code Coverage wiki page

[BenHenning]

Thanks @Rd4dev! As far as I can tell, all the failures were due to the v4 issue but I'll keep an eye out for any other build flakes that might be occurring.