Introduce `secrets.properties`

wzieba commented 1 week ago

Description

This PR splits gradle.properties into 3 files:

gradle.properties which constains only build related configuration and is now checked in into VCS
secrets.properties which contains only secrets, fetched from mobile-secrets tool (with accompanying defaults.properties)
developer.properties-example which allows to set local, custom developer configuration

These changes make the setup safer by putting secrets outside of the working repository and easier to provide build configuration changes, as no mobile-secrets update is requested to get them anymore. It also streamlines setting up the project as there's no need to copy gradle.properties-example to build the project.

dependency-tree-diff step won't succeed because we changed the build steps comparing to trunk (removed copying gradle.properties-example)

Testing information

Signing configuration

Checkout trunk and setup all secrets bundle exec fastlane run configure_apply.
Run :WooCommerce:signingReport task, copy the content
Checkout this branch, run :WooCommerce:signingReport again
Compare outputs of both executions. They should be the same.

Repeat these steps for WooCommerce-Wear module.

App secrets

Open generated BuildConfig.kt file. Make sure it contains valid secrets. You can compare content of BuildConfig.kt from build from trunk, but be aware they'll be different: unused secrets have been removed from mobile secrets.

Measure builds

Apply secrets bundle exec fastlane run configure_apply and assert, that at the end of the task Build time report of Xm Ys has been received by Apps Metrics. is printed to the console.

Developer properties

Copy developer.properties-example
Provide a change in the configuration
Assert that the change of property is reflected in generated BuildConfig.kt file.

[x] I have considered if this change warrants release notes and have added them to RELEASE-NOTES.txt if necessary. Use the "[Internal]" label for non-user-facing changes.

Reviewer (or Author, in the case of optional code reviews):

Please make sure these conditions are met before approving the PR, or request changes if the PR needs improvement:

[ ] The PR is small and has a clear, single focus, or a valid explanation is provided in the description. If needed, please request to split it into smaller PRs.
[ ] Ensure Adequate Unit Test Coverage: The changes are reasonably covered by unit tests or an explanation is provided in the PR description.
[ ] Manual Testing: The author listed all the tests they ran, including smoke tests when needed (e.g., for refactorings). The reviewer confirmed that the PR works as expected on big (tablet) and small (phone) in case of UI changes, and no regressions are added.

dangermattic commented 1 week ago

	1 Warning
:warning:	This PR is larger than 300 lines of changes. Please consider splitting it into smaller PRs for easier and faster reviews.

Generated by :no_entry_sign: Danger

wpmobilebot commented 1 week ago

📲 You can test the changes from this Pull Request in WooCommerce-Wear Android by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce-Wear Android
	Platform	⌚️ Wear OS
	Flavor	Jalapeno
	Build Type	Debug
	Commit	d5268362ffc8f7a6239b85f9315947ced82f3a8a
	Direct Download	`woocommerce-wear-prototype-build-pr12933-d526836.apk`

wpmobilebot commented 1 week ago

📲 You can test the changes from this Pull Request in WooCommerce Android by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce Android
	Platform	📱 Mobile
	Flavor	Jalapeno
	Build Type	Debug
	Commit	d5268362ffc8f7a6239b85f9315947ced82f3a8a
	Direct Download	`woocommerce-prototype-build-pr12933-d526836.apk`

wzieba commented 5 days ago

Thank you @ParaskP7 🙌 . Indeed the measure builds stopped working because I've missed updating how the project gets tracksEnabled. I've addressed the problem and extracted the value to a shared value, to reduce risk of similar mistake in the future.

ParaskP7 commented 5 days ago

👋 @wzieba and thanks for this update, quite weird and sneaky that this userEnabledTracking where within this gradle_build_scan.gradle file (I guess a leftover), thanks for moving it out of there (one more reason to migrate away of Groovy and using such patterns and onto Gradle Kotlin DSL)! 🥇

I testing this again and everything now works as expected, 🟢 light from me! 🚀

woocommerce / woocommerce-android