Open G00fY2 opened 3 months ago
Hi @G00fY2, thanks for the bug report!
Indeed, at the moment, the plugin does not support newer Gradle versions, we are working on fixing this. I will keep this issue open and can ping you one a new version is released.
Any update on this? It is now our only blocker in the pipeline.
@ArcherEmiya05 unfortunately not. As this is a bigger refactor, it might take a bit until it is finished.
@ArcherEmiya05 unfortunately not. As this is a bigger refactor, it might take a bit until it is finished.
Will it take months to finish cause we are now considering removing the plugin for now?
Unfortunately I do not know an exact ETA yet, but it will definitely take a bit.
Currently the options are downgrading Gradle (might not work in your project), or using the CLI for CI integration (Help Article HowTo). Is using the CLI an option for you? If you have any questions how, please ping me!
Unfortunately I do not know an exact ETA yet, but it will definitely take a bit.
Currently the options are downgrading Gradle (might not work in your project), or using the CLI for CI integration (Help Article HowTo). Is using the CLI an option for you? If you have any questions how, please ping me!
Yes, I hope we can use your CLI as temporary replacement instead of gradle plugin for CI/CD pipeline so that incompatibility with Gradle will no longer be a problem.
@titze Does this command guardsquare scan app/build/outputs/apk/debug/app-debug.apk
is equivalent to the plugin's uploadToAppSweepDebug
gradle task as well as guardsquare scan app/build/outputs/bundle/release/app-release.aab
to uploadToAppSweepReleaseBundle
? If yes, does it also support accepting a download url instead of file assuming that the APK or AAB artifact is downloadable and hosted in a cloud storage?
Below is the setup we will have on the pipeline.
script:
- curl -sS https://platform.guardsquare.com/cli/install.sh | sh
- export APPSWEEP_API_KEY=$APPSWEEP_API_KEY # Set AppSweep API key
- guardsquare scan app/build/outputs/apk/debug/app-debug.apk # Perform static analysis
The commands are not quite equivalent, there are two things missing (at the moment) if you use the CLI like you do:
a.a
Did you find this helpful in AppSweep that we showed in which library / your code an issue was?
Re download URL:
This is not possible at the moment. In your setup I guess it wouldn't be difficult to just curl
the apk before calling guardsquare scan
?
Can you elaborate what your use-case is here? I am curious, because maybe this is something the CLI should indeed support natively, and I can put it on the roadmap.
The commands are not quite equivalent, there are two things missing (at the moment) if you use the CLI like you do:
- if the app is name-obfuscated (e.g. with R8), the Gradle plugin also uploads the mapping file so that AppSweep can show you the real location of problems, and not just
a.a
- the gradle plugin also collects information about the dependencies in your app, and uploads this to AppSweep. With this information, AppSweep can show you which problems are directly in your code, and which in dependencies (and in which). Without using the Gradle plugin, AppSweep tries to reconstruct this as best as it can, but it will not be accurate.
Did you find this helpful in AppSweep that we showed in which library / your code an issue was?
Re download URL: This is not possible at the moment. In your setup I guess it wouldn't be difficult to just
curl
the apk before callingguardsquare scan
? Can you elaborate what your use-case is here? I am curious, because maybe this is something the CLI should indeed support natively, and I can put it on the roadmap.
Just thought it would be a good feature to be able to accept url.
Anyway it seems that the plugin is still better approach than the CLI, really hope it get fixed for newer Gradle version. We do in fact use R8 in our code and AppSweep taking extra miles to check the used libraries is good as well.
I will keep you in the loop!
If the CLI would also offer the same functionality (mappingfile, libraries), would that be a problem for you?
Integration with Gradle is always a bit tricky, so not relying on it (much) might make integration a lot smoother.
I will keep you in the loop!
If the CLI would also offer the same functionality (mappingfile, libraries), would that be a problem for you?
Integration with Gradle is always a bit tricky, so not relying on it (much) might make integration a lot smoother.
If the CLI would also offer the same functionality (mappingfile, libraries), would that be a problem for you?
Just being able to include the mapping file would probably enough reason for us to permanently decommission the plugin in favor of CLI approach.
Ok, thanks for that info! I will ping you when I know more.
@ArcherEmiya05
actually if you only want to upload the mapping file, this is already possible:
guardsquare scan my_app.apk --mapping-file mapping.txt
Keep in mind that then the library information is deduced from the app itself, and is not as accurate as if you uploaded via thge Gradle plugin. That part is currently not possible (yet) with the CLI. Essentially this means that some findings would look like they are from your own code, whereas in reality they could be from a library that you included.
The plugin is currently not compatible with Gradle 8.7+ because it uses internal Gradle APIs that are not available anymore: https://github.com/Guardsquare/appsweep-gradle/blob/9517368a13ad2673cda24e217bce8394a51ed39f/src/main/kotlin/com/guardsquare/appsweep/gradle/AppSweepPlugin.kt#L435
DefaultSelfResolvingDependency
was replaced withDefaultFileCollectionDependency
in Gradle 8.7 with this commit: https://github.com/gradle/gradle/commit/a5bd45929daffc43085c3a433c5bd6732f504749Therefore the appsweep plugin fails at configuration with the following stacktrace: