-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
fix(android)(9_0_X): production builds no longer copy AAB to distribution folder as of 9.0.1 #11645
Conversation
- Regression introduced in 9.0.1 by using newest Android gradle tool. * Google renamed built AAB file and Titanium failed to find the file. * AAB file was stilling be built, just not be copied to given destination folder. - Added APK and AAB file validation. Will now trigger build failure if files were not found.
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.
CR: PASS
android/cli/commands/_build.js
Outdated
// Verify that we can find the above built file(s). | ||
if (!await fs.exists(this.apkFile)) { | ||
this.logger.error(`Failed to find built APK file: ${this.apkFile}`); | ||
process.exit(1); |
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.
Just an FYI - I am not fond of our use of exiting the process immediately in these functions like this. Ideally we simple return an error to the callback/throw an Error (if in an async function or sync function with no callback) - and let the top-level CLI do the exiting of the process with a failure exit code. We tend to have these calls sprinkled throughout CLI related code making re-use harder if we ever want to re-use in another context.
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'll change it to throw an exception instead, which I think is fine in this case.
That said, I don't think we should throw an exception for say end-user configuration issues, because the logged stack trace would make it look like an issue on our end when it's not.
FR Passed. Studio Ver: 6.0.0.202003181504 |
JIRA: https://jira.appcelerator.org/browse/TIMOB-27852
Cherry-pick of PR: #11644