Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Create Kenya study-specific build flavor & version codes #4410

Closed
BenHenning opened this issue Jul 1, 2022 · 0 comments · Fixed by #4507
Closed

Create Kenya study-specific build flavor & version codes #4410

BenHenning opened this issue Jul 1, 2022 · 0 comments · Fixed by #4507
Assignees
@BenHenning
Labels
Impact: Low Low perceived user impact (e.g. edge cases). Impact: Medium Moderate perceived user impact (non-blocking bugs and general improvements). Z-ibt Temporary label for Ben to keep track of issues he's triaged.
Milestone
0.8 Release Block...

Comments

@BenHenning
Copy link
Member

This is needed for two reasons:

  1. We need to release another version of alpha for the Kenya study (which means again dealing with the version code confusion since that build had a never-in-GitHub-tracked version code)
  2. Flavors change the version name (which helps avoid the Kenya & standard alpha versions having conflated version names which led to some confusion when investigating whether the correct version of the app was actually deployed during the dry-run stage of the project)
@BenHenning BenHenning self-assigned this Jul 1, 2022
@BenHenning BenHenning added this to the Alpha MR5 milestone Jul 1, 2022
This was referenced Jul 3, 2022
Closed
Closed
@Broppia Broppia added Impact: Medium Moderate perceived user impact (non-blocking bugs and general improvements). issue_type_infrastructure labels Jul 6, 2022
@Broppia Broppia added the Impact: Low Low perceived user impact (e.g. edge cases). label Jul 14, 2022
This was referenced Aug 17, 2022
Merged
Merged
BenHenning added a commit that referenced this issue Aug 19, 2022
@BenHenning
Fix part of #4410, #4300, #2432: Create dedicated alpha application c…
7562fdf 
…omponent (#4414)

## Explanation
Fixes part of #4410, #4300, and #2432.

This PR refactors the existing approach for managing application-level build dependencies by splitting up OppiaApplication ApplicationComponent into two: one for the developer build, and one for alpha. The existing OppiaApplication was retrofitted to be a base abstract class for both of the flavor-specific applications, and also for the e2e test TestApplication class (which subsequently simplified that).

This has overall resulted in a decrease in complexity since it now allows us to select specific dependencies per flavor of the app which should significantly simplify ongoing release automation work, plus other flavor-specific gating that we may want to do in the future without having to rely on a human to manually enable/disable certain modules during release time.

A few other small things of note:
- ApplicationContext was removed since it seems to be barely used, and is confusing compared to the regular Context binding that's used almost everywhere
- This PR has led to the app module application package having its own Bazel BUILD file (which is a nice help toward continued modularization work)
- Most of this PR is tested by observing that the corresponding builds still work as expected, other than the changes to the manifest transformation utility
- A bunch of the new classes have been exempted for requiring tests since they (mostly) cannot be effectively tested, or are maintaining the status quo for testing these classes

## Essential Checklist
- [x] 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: ...".)
- [x] Any changes to [scripts/assets](https://github.com/oppia/oppia-android/tree/develop/scripts/assets) files have their rationale included in the PR explanation.
- [x] The PR follows the [style guide](https://github.com/oppia/oppia-android/wiki/Coding-style-guide).
- [x] The PR does not contain any unnecessary code changes from Android Studio ([reference](https://github.com/oppia/oppia-android/wiki/Guidance-on-submitting-a-PR#undo-unnecessary-changes)).
- [x] The PR is made from a branch that's **not** called "develop" and is up-to-date with "develop".
- [x] The PR is **assigned** to the appropriate reviewers ([reference](https://github.com/oppia/oppia-android/wiki/Guidance-on-submitting-a-PR#clarification-regarding-assignees-and-reviewers-section)).

## For UI-specific PRs only
N/A -- This is an infrastructure-only change.

Commits:

* Create dedicated alpha application component.

This simplifies application component management significantly and
allows individual build flavors to have their own unique module lists.

* Fix broken test per earlier changes.

* Update TransformAndroidManifestTest.kt

Correct typos.
BenHenning added a commit that referenced this issue Aug 19, 2022
@BenHenning
Fix #4410: Introduce Kenya study alpha build flavor (#4507)
17f2bcb 
## Explanation
Fixes #4410

This PR builds on #4414 by introducing a new alpha component that's specific to the team's ongoing research project in Kenya. This build serves three benefits:
1. It allows us to ensure end users can easily distinguish between alpha & study-specific alpha flavors of the app (since they will now have different build flavors).
2. It ensures we can explicitly version the binaries such that the study binary always takes precedence on Play Store.
3. It allows us to define study-specific parameters without needing manual changes during release (such as automatically enabling the learner study feature, which this PR is doing for the new build flavor).

A few important things to note:
- There are no new tests for the new components since they are mostly uninteresting to test (similar to other build flavor components).
- The new components are temporary are will be reoved (#4419 is tracking this).
- This PR is a recreation of #4420 since the new build flavor was being originally being introduced after the new beta & GA flavors (but this is no longer the case due to the beta release being delayed).
- The new build flavor is not being added to CI build tests mainly because it's unlikely for this build to break versus the alpha build (as the two are so similar), and because of the temporary nature of this version of the app.
- The new classes needed to be exempted for Gradle builds since Gradle was having difficulty with the fact that the new study-specific alpha component was a separate Dagger graph (our Gradle configuration, unlike Bazel, can't manage multiple Dagger graphs in the same build tree). This seems like a reasonable thing to do since the study-specific version of the app can't be built on Gradle, anyway.
This 
## Essential Checklist
- [x] 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: ...".)
- [x] Any changes to [scripts/assets](https://github.com/oppia/oppia-android/tree/develop/scripts/assets) files have their rationale included in the PR explanation.
- [x] The PR follows the [style guide](https://github.com/oppia/oppia-android/wiki/Coding-style-guide).
- [x] The PR does not contain any unnecessary code changes from Android Studio ([reference](https://github.com/oppia/oppia-android/wiki/Guidance-on-submitting-a-PR#undo-unnecessary-changes)).
- [x] The PR is made from a branch that's **not** called "develop" and is up-to-date with "develop".
- [x] The PR is **assigned** to the appropriate reviewers ([reference](https://github.com/oppia/oppia-android/wiki/Guidance-on-submitting-a-PR#clarification-regarding-assignees-and-reviewers-section)).

## For UI-specific PRs only
This PR has no user-facing side effects except the fact that the version name is different now for the study-specific version of the app (which doesn't seem particularly important to show a video/screenshot for).

Commits:

* Create dedicated alpha application component.

This simplifies application component management significantly and
allows individual build flavors to have their own unique module lists.

* Fix broken test per earlier changes.

* Add Kenya study-specific alpha build flavor.

This new build flavor automatically enables the study-specific learner
study feature flag.

Cherry-pick of eef2f4c from the
original #4420.

* Update build_flavors.bzl

Remove beta version declaration since that doesn't belong in this branch.

* Post-CP fixes.

* Fix Gradle builds.

* Update TransformAndroidManifestTest.kt

Correct typos.
@BenHenning BenHenning added the Z-ibt Temporary label for Ben to keep track of issues he's triaged. label Sep 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@BenHenning BenHenning

Labels
Impact: Low Low perceived user impact (e.g. edge cases). Impact: Medium Moderate perceived user impact (non-blocking bugs and general improvements). Z-ibt Temporary label for Ben to keep track of issues he's triaged.
Projects
[Team] Developer Workflow & Infrastructure - Android
Archived in project
Milestone
0.8 Release Blockers (Alpha MR5)
Development

Successfully merging a pull request may close this issue.

Fix #4410: Introduce Kenya study alpha build flavor oppia/oppia-android
3 participants
@seanlip @BenHenning @Broppia