Status Update
Comments
ku...@google.com <ku...@google.com>
[Deleted User] <[Deleted User]> #3
Hello there,
When following the steps you mentioned, the URL returned in my test environment is the /dev one and not the one you mention. Hence, I am not able to reproduce this behavior.
Would you mind providing more information regarding this and eventually a list of steps in order to investigate this further?
Moreover, did you notice this particular behavior only with this script or it has happened with others as well?
to...@sap.com <to...@sap.com> #4
When executing ScriptApp.getService().getUrl()
as a function directly it indeed works as you explained. We also receive the /dev url.
The way we deploy and test our add-on is on Google Calendar. We want to expose the Script URL through createSettingsUrlFunction
for the calendar addon.
Attaching the manifest file and the function we use for the createSettingsUrlFunction
function.
Attaching also a screenshot showing the mismatch between the Deployment ID and the URL generated in Google Calendar.
Attaching a screenshot taken from the script editor - showing the deployed version id.
Bottom line: I would expect the Google Calendar settings link to return the version deployed and not anything else.
Expected URL returned by ScriptApp.getService().getUrl()
:
Actual URL returned by ScriptApp.getService().getUrl()
:
Description
If I set testCoverageEnabled to true in the build.gradle for a library module in a multi-module Android project, then the .exec file generated for running unit tests is nearly empty, and any reports generated from it will show 0% code coverage.
Setting testCoverageEnabled to false results in a much larger .exec file that displays the proper coverage in generated reports. (however, testCoverageEnabled is required so that I can use these binaries to gather coverage numbers for on-device instrumentation tests)
Sample:
Environment:
Steps:
../gradlew clean testDebugUnitTest
../gradlew clean testDebugUnitTest
testCoverageEnabled
tofalse
.