-
Notifications
You must be signed in to change notification settings - Fork 9
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.
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
chore: Create workflow to build sample app with latest SDK release #457
chore: Create workflow to build sample app with latest SDK release #457
Conversation
Sample app builds 📱Below you will find the list of the latest versions of the sample apps. It's recommended to always download the latest builds of the sample apps to accurately test the pull request. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #457 +/- ##
============================================
+ Coverage 41.98% 51.86% +9.88%
- Complexity 259 291 +32
============================================
Files 99 96 -3
Lines 2320 2570 +250
Branches 344 352 +8
============================================
+ Hits 974 1333 +359
+ Misses 1247 1133 -114
- Partials 99 104 +5 ☔ View full report in Codecov by Sentry. |
Build available to test |
📏 SDK Binary Size Comparison ReportNo changes detected in SDK binary size ✅ |
touch "samples/local.properties" | ||
echo "cdpApiKey=${{ secrets.CUSTOMERIO_JAVA_WORKSPACE_CDP_API_KEY }}" >> "samples/local.properties" | ||
echo "siteId=${{ secrets.CUSTOMERIO_JAVA_WORKSPACE_SITE_ID }}" >> "samples/local.properties" | ||
echo "sdkVersion=${{ env.SDK_VERSION }}" >> "samples/local.properties" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The sample app build scripts already check for sdkVersion
here and this will cause the public release to be used instead of local project
end | ||
end | ||
|
||
lane :build_sample_app_for_sdk_release do |values| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I opted for creating a new lane since the existing one is already fairly complicated. Also if we decide to move to a single app, we can just deprecate the older lane.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I'm unsure about this because again, both lanes have 70% of the same code, apart from some hardcoded values in this lane. I don't mind separate lane, but then could we probably move the shared code in methods that both lanes can utilize?
Also, could you point out the complicated parts in the other lane so we can see how we can make them less complicated in future?
for example, something like this, ensure, that when you are testing a feature branch we don't show the version of the SDK in user agent, but rather the branch its being tested on.
UI.important("Updating the SDK's source code version to non-production version. This allows the sample apps to show the SDK version at runtime for app user to better understand the version of the SDK they are running.")
sh("../../../scripts/update-version.sh \"#{new_app_version}.#{new_build_number}\"")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the implementation! While both workflows/lanes serve different purposes, I notice there's significant code duplication that could lead to several issues:
such as maintenance burden and being error prone.
I have added couple of suggestions, let me know if they are helpful. Even if we don't move towards a more configurable approach we should at least remove duplication and use shared resources.
end | ||
end | ||
|
||
lane :build_sample_app_for_sdk_release do |values| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I'm unsure about this because again, both lanes have 70% of the same code, apart from some hardcoded values in this lane. I don't mind separate lane, but then could we probably move the shared code in methods that both lanes can utilize?
Also, could you point out the complicated parts in the other lane so we can see how we can make them less complicated in future?
for example, something like this, ensure, that when you are testing a feature branch we don't show the version of the SDK in user agent, but rather the branch its being tested on.
UI.important("Updating the SDK's source code version to non-production version. This allows the sample apps to show the SDK version at runtime for app user to better understand the version of the SDK they are running.")
sh("../../../scripts/update-version.sh \"#{new_app_version}.#{new_build_number}\"")
1fdad4c
to
bac56b2
Compare
@Shahroz16 I've extract common code in both Fastlane and the workflow and it's now shared. |
bac56b2
to
279c8cb
Compare
279c8cb
to
f9f32c7
Compare
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good just one suggestion regarding secrets simplified usage
|
|
Motivation
At the moment we don't have any sample apps that is built by pulling our SDK releases from Maven Central. That is the closest form to what our customers experience. So we want to start building those sample apps to:
Proposal
public
Deploy SDK
workflow runs successfully