-
Notifications
You must be signed in to change notification settings - Fork 38
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
Avoid eager initialization of bugsnag tasks #266
Conversation
13e618e
to
cba71b7
Compare
36514d1
to
5056291
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.
Nice!
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.
Do we have a ticket to fix & re-enable the newly skipped tests? I'm a bit concerned by the loss of coverage, but otherwise this looks good
Co-authored-by: Joe Haines <hello@joehaines.co.uk>
PLAT-4842 should cover allowing the tests to be enabled once more - this is just an issue with the order in which requests are received on particular AGP versions. |
Goal
Avoids eager initialization of bugsnag tasks by supporting Task Configuration Avoidance. Previous changesets such as #227 made pre-requisite changes, but the use of
task.get()
triggered creation of bugsnag tasks during the Configuration phase which impacts build performance.Changeset
This changeset builds on #261 which has been reviewed by @fractalwrench. The majority of the new changes in this PR relate to the E2E scenarios as the request order has changed due to the different mechanism used to register bugsnag tasks.
BugsnagUploadProguardTask
has been updated to use aConfigurableFileCollection
and@InputFiles
for the mapping file property. These do not require a file to exist at the time of task registration - which would otherwise fail the build as the mapping file doesn't exist until late in the build lifecycle. This mirrors the approach already used forBugsnagReleasesTask
.On AGP 3.5.X the tasks add a
mustRunAfter
dependency on the package task, as the ordering is otherwise incorrect and the mapping file would not exist. This leads to a degradation as configuration avoidance can't be supported, and also results in manual invocations of the upload/bundle upload tasks failing. This is seen as acceptable due to the low number of users on this version, the less common use-case, and a simple workaround of updating AGP version.Tests