ioki-mobility / sentryproguardgradleplugin Goto Github PK

It reports:

`:app:uploadSentryProguardUuidForXYZRelease` of type `com.ioki.sentry.proguard.gradle.plugin.tasks.UploadUuidToSentryTask`: invocation of 'Task.project' at execution time is unsupported.

While implementing #65 I realized that the javadoc.jar is empty.
It doesn't contain any docs.

This should be fixed.

TODOS:

• Adjust POM file
• Change groupId? And artifact?
• Add javadoc to publication
• Add sources to publication
• Sign artifacts
• Add sonatype snapshot repository to publishing
• Add GH Actions/CD for automatic releasing
• Add credentials to GH Actions secrets
• Adjust README
• ...?

We have tests already in place. We only need a GitHub Actions for running those 🙃

Currently the project is just open sourced but not used.
We should make it publishable by adding the maven-publish plugin and then publish it "somewhere".
Either via jitpack or using the Gradle plugin portal.

Maybe it makes more sense to create a extension to set up the sentry related information instead of proving them via Gradle properties.
Could look like:

sentry {
  org.set("sentry_org")
  project.set("sentry_project_prop")
  authToken.set("sentry_auth_token_prop")
}

With that solution we could still use properties 🙂

sentry {
  org.set(properties("sentry_org_prop"))
  org.set(properties("sentry_project_prop"))
  org.set(properties("sentry_auth_token_prop"))
}

See https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-gradle-registry

See https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:using_a_predicate

Currently we ship AGP 7.4.1

We should make sure that the plugin will not break with new AGPs.
For that we could make an (easy) integration test and a junit5 parameterized tests to test different variations.

AGPs versions can be found here:
https://maven.google.com/web/index.html?q=gradle#com.android.tools.build:gradle

junit5 parameterized tests:
https://junit.org/junit5/docs/current/user-guide/#writing-tests-parameterized-tests

Another option to junit5 parameterized tests would be to leaverage the work to the CI (GitHub Actions):
https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs

But not sure how the latter would/could work and how it would/could look like 🤷
Benefit would be that each test run in parallel instead of sequencelly (in case of junit5)

If not already done with #18

See https://docs.github.com/en/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot

Currently we are only supporting MacArm and LinuxX86 because of the cli we download.
Actually there are more cli types available to download... We should do that.

See:

• https://medium.com/androiddevelopers/gradle-and-agp-build-apis-taking-your-plugin-to-the-next-step-95e7bd1cd4c9
• https://github.com/android/gradle-recipes/tree/agp-7.4/Kotlin%2FmanifestReplacementTest

As of today, we only support the default build types debug and release.
While we disable the UUID generation as well as the tasks for debug we do it on release.

Anyhow, it is possible to create more build types with different configs.
To make this plugin more generic we should check each build type if minify is enabled and do the uuid and task generation process for all of them...

Right now we can't make sure that "an" UUID was placed into the AndroidManifest.
We might want to check this.

The generated AndroidManifest can be found at
build/intermediates/packaged_manifests/XRelease/AndroidManifest.xml

Currently the CLI version is hardcoded:

We should make it possible that plugin consumers can change the version via extensions (see also #4).

To note:
Updating the version of the CLI might break the uploading in case the CLI parameters change.

Currently we always sign artifacts.
This however lead to problems. Not only when build locally when no signing key and/or password is available but also in PRs by contributors. See #73

We should only sign artifacts in our CI when we publish to the sonatype/github repos.

Currently we are using a hardcoded version of the sentry cli. Even if we make this configurable in the future (see #6) wen (this repo) wants to somehow notified as soon as there is a new release of the cli so we can update it.

As a first solution we might want to use a GH action that checks sentry cli repo for a new release every week and in case there is a new version it creates a PR 🤷‍♂️ maybe an issue would be enough too...

Right now we try to create a PR even when it might be the case an PR (or branch) with that name already exists.
In this case the workflow fails.
However, it shouldn't fail but silently finish because this is not an issue 🙃

Also include changelog / link to release in body