RUMM-2244: Sourcemap upload script#222
Conversation
| } | ||
|
|
||
| // TODO service name per variant? | ||
| def serviceName = datadogConfig.SERVICE_NAME ?: androidExtension.defaultConfig.applicationId |
There was a problem hiding this comment.
Question: should we be able to provide this as an environment variable to get a similar behaviour on iOS and Android?
There was a problem hiding this comment.
Can you please point me how it is defined/used in case of iOS?
There was a problem hiding this comment.
for iOS I thought we could specify it in the Build phase. But now I feel this is a bit too hard to implement.
Now there is an .xcode.env file in the ios folder with env variables that are going to be used for the build.
I thought we could do a .datadog.sourcemaps.env file at the root of the project, which could contain variables like:
- DATADOG_API_KEY
- DATADOG_SITE
- DATADOG_ANDROID_SERVICE
- DATADOG_IOS_SERVICE
This file can be gitignored so the variables could also be specified in the CI without having to create or decrypt a file.
In the plugin, we could try to source it if is present, then use the env variable that is present.
I think there is an advantage of having only 1 file for iOS and Android, and it integrates nicely with the CI, Fastlane or the .xcode.env (we can add a line to source our file from this one).
What do you think?
There was a problem hiding this comment.
the only downside is that not everything should be sourced (service name is not read as env variable by datadog-ci, if I'm not wrong?) and there is no source on Windows (but it is not a big deal, with Gradle we can source by ourselves), but overall I'm ok with such common file.
There was a problem hiding this comment.
Indeed the service name is not read as an environment variable by datadog-ci, I don't think it should be (if they want to directly use this command, users can create a script that gets this variable and feeds it into the script).
I think the advantage of having 1 config file is that it makes it easy for devs to know where to put things.
| def serviceName = datadogConfig.SERVICE_NAME ?: androidExtension.defaultConfig.applicationId | ||
|
|
||
| if (serviceName == null) { | ||
| throw new GradleException("Cannot determine service name.") |
There was a problem hiding this comment.
I believe a lot of people are going to feel helpless at short messages.
We could improve this message by adding a few troubleshooting actions.
For example:
"Make sure that you've applied the datadog plugin in your android/app/build.gradle (or equivalent) and it has a defaultConfi applicationId."
"You can specify a custom service from the datadog.properties file"
| def buildVersion = androidExtension.defaultConfig.versionCode | ||
|
|
||
| if (releaseVersion == null) { | ||
| throw new GradleException("Cannot determine application version," + |
There was a problem hiding this comment.
Same thing here, I think we should assume that the person reading this message is not familiar with android development.
|
The file needs to be added to the |
|
To test this with a new version of datadog-ci:
In your project with a new version of the core package
|
818a6a9 to
86e8aed
Compare
86e8aed to
4bc959e
Compare
|
This PR is good for me, let's wait for the unminification to be working in staging before merging it. |
| } | ||
|
|
||
| uploadTask.dependsOn bundleTask | ||
| bundleTask.finalizedBy uploadTask |
There was a problem hiding this comment.
why this also ? isn't the first dependency enough ?
There was a problem hiding this comment.
No, not enough. Without uploadTask.dependsOn bundleTask there will be an error if user runs upload task, but there is no bundle task run before by some reason. Without bundleTask.finalizedBy uploadTask there won't be automatic upload after bundle task is finished.
There was a problem hiding this comment.
I see, tks for the explanation. That makes sense.
| } | ||
| } | ||
|
|
||
| def runShellCommand(List<String> command, Map<String, String> env = [:]) { |
There was a problem hiding this comment.
there's already an Exec gradle task from which you can inherit one. Here's the example of the one I did when working for the nightly tests coverage:
tasks.create("checkNightlyTestsCoverage", Exec::class.java) {
this.group = "datadog"
val generateApiTasks = allprojects.mapNotNull { it.tasks.findByName("generateApiSurface") }
setDependsOn(generateApiTasks)
setCommandLine(
"python3",
"instrumentation-tools/nightly_tests_code_coverage.py",
"-t $threshold"
)
}
There was a problem hiding this comment.
yes, inside runShellCommand there is a call to exec, just the body of the upload task created is responsible for the configuration phase, and actual upload is triggered in the doFirst.
There was a problem hiding this comment.
Yup, sorry didn't check your last commit ;)
a3c49f3 to
454c4a4
Compare
What does this PR do?
This changed brings a task to upload JS source maps/bundles for Android by getting their location and passing it to the
datadog-citool. Currently it only supports application module (hence relying on the specific project) and should be applied asapply fromin the end of the app module'sbuild.gradle.It can read properties from the
datadog-sourcemaps.propertiesfile (currently reading only service name property + API key), which should be located in the root dir of React Native project. Content should be in thekey=valueformat.For the custom service name the logic is to check if there is
SERVICE_NAME_ANDROID_%FLAVOR%key first, if not checkSERVICE_NAME_ANDROID, otherwise fallback toapplicationId.When applied it will add the necessary upload tasks for the variants which have bundling enabled. This task will be automatically run after bundle task completes.
Review checklist (to be filled by reviewers)