Randomizing mapping_file_id for each build prevents gradle build cache #2

[lamphamTL]

[REQUIRED] Step 2: Describe your environment

• Firebase Component: Firebase Crashlytics Gradle Plugin 3.0.1
• Google Play Service Gradle Plugin: 4.4.1

[REQUIRED] Step 3: Describe the problem

This is a follow up issue of the previous one which has been locked by the bot.
I've tried the version 3.0.1 as suggested here but the task InjectMappingFileIdTask keeps generating a brand new mapping_file_id with the same input sources.

Steps to reproduce:

Same steps as here

[google-oss-bot]

I found a few problems with this issue:

• I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
• This issue does not seem to follow the issue template. Make sure you provide all the required information.

[lehcar09]

Hi @lamphamTL, thank you for reaching out. I was able to reproduce the issue using the latest Crashlytics plugin 3.0.1. I'll notify our engineers and get back to you. Thanks!

[mrober]

@lamphamTL this is an unfortunate side effect of the way Crashlytics works. I did attempt to make the task smarter, and not generate a new mapping file id when the app source didn't change. But this created other issues, so we were forced to revert it. I would like to fix this, but since it is not a regression it's not a high priority right now.

During development, if your builds have obfuscation or mapping file upload disabled, then the task will cache properly because it will generate a mapping file id of 0. Only builds with obfuscation will cause this. Would this be ok for your use case? Or is there a reason you want to repeatedly build release builds? If I understand your use case better I might be able to offer some workaround to mitigate the issue.

[lamphamTL]

hey @mrober,
We run different tasks (assemble and unit test) with release variant on CI for different flow (for internal/external publishing and PR validation), and then use remote build cache. Which mean we build the release variant very frequently and missing this cache is quite impactful (increase build time, cost remote cache traffic for nothing).

I have few questions
Why do you have to create and upload this mapping file id before the build?
Is this id used during the build?
I wonder if it is possible that you do this after the obfuscation (or more precisely after the mapping file gets generated, then you may set the hash of that file to the mapping file id and upload it)

[lamphamTL]

hey @mrober 👋
Any updates from your side?

[mrober]

Hi @lamphamTL we create the mapping file id early because we inject it into the app as an Android resource. We did try doing this later in the build process, but that creates a circular dependency on any other Gradle plugin that requires the Android resources as input to generate code. This also means we cannot do it after the mapping file has been generated.

We have considered other methods to pass the mapping file id into the app, but changing this would make a complicated compatibility chart between versions of the Gradle plugin and versions of the SDK. This has come up a couple times now so it is on my radar, but I cannot promise any timeline unfortunately. And this will likely be gated behind a property for a long time due to the compatibility issue.

[lamphamTL]

@mrober Thanks for the explanation, very clear.
is there an API for setting this value on client side?
We got the exactly same problem with New Relic SDK (the difference is the generated id is included in a generated java class instead of resources) and we changed this id to a hash calculated from the app version.

[mrober]

That is a nice idea, I will consider providing a way to support manually managing the mapping file id. Just be very careful you don't overwrite mapping files by uploading a new file with the same id, or fail to upload a new file because the id didn't change. Using the app version will not work well for this because you might have another engineer hit "run" in Android Studio, and clobber your uploaded mapping file.

[lamphamTL]

yeah, we will only intercept this value for builds that we don't need crashlytics (PR compilation checks, unit tests etc.., and we have a specific app version format for these builds)