Fix part of #6106: Add Release Playbook wiki page - #6352
Open
Sandesh282 wants to merge 11 commits into
Open
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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 |
Contributor
Coverage ReportResultsCoverage Analysis: SKIP ⏭️ This PR did not introduce any changes to Kotlin source or test files.
|
Sandesh282
changed the title
Contributor
Coverage ReportResultsNumber of files assessed: 197 Passing coverageFiles with passing code coverage
Exempted coverageFiles exempted from coverage
|
|
Hi @Sandesh282, I'm going to mark this PR as stale because it hasn't had any updates for 7 days. If no further activity occurs within 7 days, it will be automatically closed so that others can take up the issue. |
oppiabot
Bot
added
the
stale
Sandesh282
marked this pull request as ready for review
August 23, 2026 16:52
oppiabot
Bot
removed
the
stale
adhiamboperes
requested changes
Aug 27, 2026
adhiamboperes
left a comment
adhiamboperes
left a comment
Contributor
There was a problem hiding this comment.
Thanks @Sandesh282! PTAL.
…column, deploy ordering
adhiamboperes
approved these changes
Aug 28, 2026
adhiamboperes
left a comment
adhiamboperes
left a comment
Contributor
There was a problem hiding this comment.
I think the changes look good. Thanks @Sandesh282!
Contributor
Coverage ReportResultsNumber of files assessed: 348 Failing coverage
Passing coverageFiles with passing code coverage
Exempted coverageFiles exempted from coverage
|
seanlip
requested changes
Aug 28, 2026
seanlip
left a comment
seanlip
left a comment
Member
There was a problem hiding this comment.
Thanks @Sandesh282, left a few notes. PTAL.
| After the initial deployment, progressively increase the rollout using `update_rollout.yml`. | ||
| Monitor Firebase Crashlytics between each step; halt and investigate if crash rates spike. | ||
|
|
||
| | Day | `rollout_fraction` | Actual rollout | Action | |
Member
There was a problem hiding this comment.
These look like integers rather than "fractions"?
Collaborator
Author
There was a problem hiding this comment.
They are in permille (thousandths out of 1000), so 100 = 10%, 1000 = 100%. Added a note below the table to clarify the unit.
Member
There was a problem hiding this comment.
But then shouldn't the name be something like "rollout_permille", not "rollout_fraction"? The integer here is still not a fraction.
Collaborator
Author
There was a problem hiding this comment.
rollout_fraction is already the established parameter name in update_rollout.yml (the workflow input, job name, and Bazel target are all named accordingly). Keeping the same name in the playbook table makes it easy for release coordinators to directly map the doc to the actual workflow input when triggering a run.
PS: The note directly below the table already clarifies the permille semantics: "rollout_fraction is specified in permille (thousandths out of 1000) as required by the Play Console API — 100 means 10%, 1000 means 100%."
Member
There was a problem hiding this comment.
Yes, I am actually suggesting that that name is misleading throughout and should be changed, not just here, but in the workflows. This should probably have been caught during earlier review.
If a variable does not actually represent a fraction, it should not be called a fraction.
Could you please look into this? Is there an external constraint that forces us to keep the incorrect naming?
Contributor
There was a problem hiding this comment.
@Sandesh282, it may be useful to explain why we user permille instead of percent
Collaborator
Author
There was a problem hiding this comment.
The Play Console API's userFraction field accepts a decimal from 0 to 1 with sub-1% precision (e.g. 0.005 = 0.5%). Using percent integers [0, 100] would limit steps to whole percentages and couldn't represent values like 0.5%. Permille [0, 1000] covers the same sub-1% granularity while keeping the workflow input as a plain integer; the script converts it to the API decimal via rolloutFraction / 1000.0. The name rollout_fraction mirrors the API's own userFraction field name, which is why we kept it consistent throughout.
Member
There was a problem hiding this comment.
Hi @Sandesh282, that is not an adequate reason.
The userFraction field is correctly named in the Play Console API because the value it stores is a fraction (in this case, a decimal from 0 to 1).
Our rolloutFraction, however, is named misleadingly, because it does not store a fraction, and the value that it stores is instead an integer from 0 to 1000 that is supposed to be treated as a permille. Developers reading this code will naturally assume a _fraction is a float between 0.0 and 1.0 (matching the API's behavior).
Could we update the workflow/variable name to rollout_permille or similar to reflect the actual unit being used?
Note that I am not suggesting that we use percent instead. I am talking about naming the field in a way that is not misleading.
Collaborator
Author
There was a problem hiding this comment.
I understand. I had already added a sentence with an example explaining what the number represents. I think this makes values like 1000 or 100 less ambiguous, since readers can refer to the example to understand what the value means.
Member
There was a problem hiding this comment.
@Sandesh282 We are talking about two different things here. The message for the users of the feature is good, but the problem I am discussing is the name of the variable in the code, which I still think should be fixed to reflect the type of value that it stores.
|
|
||
| ## 2. Changelog Review | ||
|
|
||
| The **Generate Changelogs** workflow |
Member
There was a problem hiding this comment.
I understand that this is supposed to trigger when version.bzl is updated, but when does that latter event happen? Can you explain?
Also, is the release coordinator ever supposed to run this manually? If so, in what circumstances? Please explain.
Collaborator
Author
There was a problem hiding this comment.
version.bzl is bumped by the RC at the start of each release cycle as part of the pre-release step in §3 that push triggers Generate Changelogs automatically. The manual workflow_dispatch option exists for cases where the auto-trigger didn't fire or the changelog needs to be regenerated after corrections. Updated the §2 intro to explain both triggers.
|
|
||
| ### Pre-release | ||
|
|
||
| - [ ] Confirm `MINOR_VERSION` is bumped in `version.bzl` and the changelog PR is merged (§2). |
Member
There was a problem hiding this comment.
What does the RC do if it hasn't been bumped or the PR hasn't been merged?
Also, generally, is this step just a confirmation step or must the RC merge the changelog PR or bump the minor version directly? If the former, it might be worth explaining briefly what process was supposed to result in that happening.
Collaborator
Author
There was a problem hiding this comment.
The RC owns both steps directly. Split the original confirmation item into two explicit action items:
(1) RC bumps MINOR_VERSION in version.bzl which triggers Generate Changelogs automatically; and
(2) RC reviews and merges the changelog PR. Added a hard gate: do not cut the release branch until the changelog PR is merged
|
Hi, @Sandesh282, the LGTM Label has been removed because the changes were requested on this PR. Thanks!. |
Contributor
Coverage ReportResultsNumber of files assessed: 354 Passing coverageFiles with passing code coverage
Exempted coverageFiles exempted from coverage
|
Collaborator
Author
|
cc/ @seanlip. |
seanlip
reviewed
Aug 31, 2026
seanlip
left a comment
seanlip
left a comment
Member
There was a problem hiding this comment.
Thanks, this looks generally good. Just a couple more notes.
| After the initial deployment, progressively increase the rollout using `update_rollout.yml`. | ||
| Monitor Firebase Crashlytics between each step; halt and investigate if crash rates spike. | ||
|
|
||
| | Day | `rollout_fraction` | Actual rollout | Action | |
Member
There was a problem hiding this comment.
But then shouldn't the name be something like "rollout_permille", not "rollout_fraction"? The integer here is still not a fraction.
|
|
||
| ### Pre-release | ||
|
|
||
| - [ ] Bump `MINOR_VERSION` in `version.bzl`. This push triggers **Generate Changelogs** |
Member
There was a problem hiding this comment.
Link "Generate Changelogs" to the section above. Ditto below.
Collaborator
Author
|
@seanlip PTAL! |
|
Unassigning @Sandesh282 since a re-review was requested. @Sandesh282, please make sure you have addressed all review comments. Thanks! |
Contributor
Coverage ReportResultsNumber of files assessed: 346 Passing coverageFiles with passing code coverage
Exempted coverageFiles exempted from coverage
|
Collaborator
Author
|
@seanlip PTAL! |
|
Unassigning @Sandesh282 since a re-review was requested. @Sandesh282, please make sure you have addressed all review comments. Thanks! |
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
3 participants
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.
Fixes part of #6106
Explanation
This PR adds the Release Playbook wiki page (
wiki/Release-Playbook.md) — a practical, step-by-step coordinator guide for running Oppia Android releases using the automated pipeline introduced in the #6106 PR series.The page is structured as a set of actionable checklists covering the four main coordinator workflows:
auto_release_alpha.ymlbuild, distributing to QA via Firebase, and deploying to the alpha Play Console track.generate_changelog.yml.update_rollout.yml, with Crashlytics monitoring at each step.The page is intentionally thin on conceptual detail — it links to App and Feature Release Process for background and to In-Depth Release Reference for manual fallback procedures.
Essential Checklist
Disclosure of LLM Usage
AI was used for code completion, drafting wiki content, and research.