Fix part of #6106: Add In-Depth Release Reference wiki page - #6355
Fix part of #6106: Add In-Depth Release Reference wiki page#6355Sandesh282 wants to merge 3 commits into
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 |
Coverage ReportResultsCoverage Analysis: SKIP ⏭️ This PR did not introduce any changes to Kotlin source or test files.
|
|
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. |
|
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. |
| manually outside of its normal trigger. It is linked from the | ||
| [Release Playbook](Release-Playbook.md). |
There was a problem hiding this comment.
| manually outside of its normal trigger. It is linked from the | |
| [Release Playbook](Release-Playbook.md). | |
| manually outside of its normal trigger. |
Not necessary?
| 1. [generate\_changelog.yml fails](#1-generate_changelogymlfails) | ||
| 2. [auto\_release\_alpha.yml fails](#2-auto_release_alphaymlfails) | ||
| 3. [pull\_latest\_lesson\_versions.yml fails](#3-pull_latest_lesson_versionsymlfails) | ||
| 4. [deploy\_updated\_changelog.yml fails](#4-deploy_updated_changelogymlfails) | ||
| 5. [build\_and\_sign.yml fails](#5-build_and_signymlfails) | ||
| 6. [deploy\_to\_firebase.yml fails](#6-deploy_to_firebaseymlfails) | ||
| 7. [deploy\_to\_play\_console.yml fails](#7-deploy_to_play_consoleymlfails) | ||
| 8. [update\_rollout.yml fails](#8-update_rolloutymlfails) |
There was a problem hiding this comment.
Same feedback as before: refer to workflows by their display names
| The workflow exits cleanly (no error). No action needed unless a release is urgent — in that | ||
| case, manually dispatch the workflow or extend the commit search limit via `workflow_dispatch` | ||
| inputs. |
There was a problem hiding this comment.
-
Please provide further isntructions to manually dispatch the workflow.
-
or extend the commit search limit via
workflow_dispatchinputs.
How is this possible?
| **Case C — Workflow succeeded but `build_and_sign.yml` was not dispatched:** | ||
|
|
There was a problem hiding this comment.
Can you give an example of how this scenario might come about?
| Manually force-push the `latest-alpha` tag to the desired commit and then trigger | ||
| `build_and_sign.yml`: |
There was a problem hiding this comment.
How can"Manually force-push the latest-alpha tag" be done?
|
|
||
| **Manual fallback:** | ||
|
|
||
| 1. Obtain `prod_server.key` from the repository secret (ask the infrastructure team). |
There was a problem hiding this comment.
It's best to ask the tech leads to perform this recovery, because the prod server key will likely not be distributed for security reasons.
|
|
||
| **What it does:** Downloads the latest lesson versions from the Oppia production server and | ||
| opens a PR updating `config/lessons/*.textproto`. | ||
|
|
There was a problem hiding this comment.
Under what circumstance is the workflow likely to fail, such that one of the recovery steps isn't manual dispatch of the workflow?
| | Changelog missing | Ensure `config/changelogs/<version>.md` exists and is merged to `develop` | | ||
| | Active edit session conflict | Wait ~5 minutes for the previous Play API session to expire, then retry | | ||
|
|
||
| **Manual fallback — Play Console web UI:** |
There was a problem hiding this comment.
The section is missing info about how to manually freeze a bundle.
| - `version`: e.g. `0.18` | ||
| - `flavor`: `alpha`, `beta`, or leave blank for the default changelog | ||
|
|
||
| **Manual fallback — run script locally:** |
There was a problem hiding this comment.
I believe changelogs can be manually edited eithing Play Console.
|
Unassigning @adhiamboperes since the review is done. |
|
Hi @Sandesh282, it looks like some changes were requested on this pull request by @adhiamboperes. PTAL. Thanks! |
Fixes part of #6106
Explanation
The Oppia Android release pipeline has been progressively automated, but the tooling for manual fallback — what a coordinator should do when a workflow fails mid-run — has lived nowhere accessible. This PR adds the In-Depth Release Reference wiki page, which is the manual fallback guide for every automated workflow in the release pipeline.
The page covers all 8 workflows in order: generate_changelog.yml, auto_release_alpha.yml, pull_latest_lesson_versions.yml, deploy_updated_changelog.yml, build_and_sign.yml, deploy_to_firebase.yml, deploy_to_play_console.yml, and update_rollout.yml. For each, it documents the normal trigger and purpose, then gives copy-pasteable bazel run commands a coordinator can run locally to replicate what the workflow does. Where a workflow has multiple failure modes (e.g. auto_release_alpha.yml can fail with "no commits", "no passing CI", or a dispatch failure), each case is addressed separately.
The page is cross-linked from the Release Playbook so that every automated step in the playbook has a direct path to its manual equivalent.
Essential Checklist
Disclosure of LLM Usage
AI was used for code completion, drafting wiki content, and research.