ci: add android and compose lint [WPB-9287]

[vitorhugods]

WPB-9287 Compose Detekt Rules

---

PR Submission Checklist for internal contributors

• The PR Title

  • conforms to the style of semantic commits messages¹ supported in Wire's Github Workflow²
  • contains a reference JIRA issue number like SQPIT-764
  • answers the question: If merged, this PR will: ... ³

• The PR Description

  • is free of optional paragraphs and you have filled the relevant parts to the best of your ability

---

What's new in this PR?

Issues

There are many localisation, performance and other hidden bugs in our app that we aren't aware of.

Solutions

We could start by adding Lint checks. Extra: adding compose lint checks.

Add these check to the codestyle workflow to catch new smelly stuff as PRs are raised.

For now, I've added all the current bugs to the baseline files, generated with run ./gradlew updateLintBaseline.

The lint configuration is done in configureKotlinAndroid function, shared by all of our Android gradle modules.

Testing

Just run ./gradlew lint on the root of the project.

Attachments

When running locally, we can also open the HTML file for easier reading. This is what is currently seen if we take out the baseline file:

Biggest offender is the ImpliedQuantity check for localisation:

---

PR Post Merge Checklist for internal contributors

• If any soft of configuration variable was introduced by this PR, it has been added to the relevant documents and the CI jobs have been updated.

---

References

1. https://sparkbox.com/foundry/semantic_commit_messages
2. https://github.com/wireapp/.github#usage
3. E.g. feat(conversation-list): Sort conversations by most emojis in the title #SQPIT-764.

[pull-request-size]

Ups 🫰🟨

This PR is too big. Please try to break it up into smaller PRs.

[github-actions]

Test Results

927 tests   927 ✅  14m 52s ⏱️
123 suites    0 💤
123 files      0 ❌

Results for commit 1454e46.

♻️ This comment has been updated with latest results.

[AndroidBob]

Build 4860 succeeded.

The build produced the following APK's:

• com.wire.android-v4.7.0(9733527)(9733527)-staging-compat.apk

[Garzas]

Code looks good but now build will take longer and I'm thinking how to solve that 🤔
(Lint file has 30MB of logs)

[AndroidBob]

Build 4864 succeeded.

The build produced the following APK's:

• com.wire.android-v4.7.0(9734090)(9734090)-staging-compat.apk

[vitorhugods]

Code looks good but now build will take longer and I'm thinking how to solve that 🤔 (Lint file has 30MB of logs)

The logs seem triggered by AboutLibraries. Maybe we can go around it someway.

The main issue seems unrelated to that, as more people seem to face issues with GH Actions + Lint: https://stackoverflow.com/a/70010526

[github-actions]

APKs built during tests are available here. Scroll down to Artifacts!

[AndroidBob]

Build 4868 succeeded.

The build produced the following APK's:

• com.wire.android-v4.7.0(9735613)(9735613)-staging-compat.apk

[Garzas]

As I understand those baseline's were added to in future remove those ignores and for future releases already check new places where we may have those issues?

[vitorhugods]

Yes. Using lintDebug was skipping :app's lint. Now it's fixed.

[AndroidBob]

Build 4879 succeeded.

The build produced the following APK's:

• com.wire.android-v4.7.0(9740365)(9740365)-staging-compat.apk

[github-actions]

APKs built during tests are available here. Scroll down to Artifacts!

[AndroidBob]

Build 4893 succeeded.

The build produced the following APK's:

• com.wire.android-v4.7.0(9741297)(9741297)-staging-compat.apk

[yamilmedina]

Looks fantastic, thanks for picking up an old collective topic 🥇

One question, how this lint vs. a detekt plugin for compose for example differs performance wise or in terms of maintainability ?

Maybe we could be better off reusing the same tool, in this case detekt, than introducing a new one 🤔

[vitorhugods]

Looks fantastic, thanks for picking up an old collective topic 🥇

One question, how this lint vs. a detekt plugin for compose for example differs performance wise or in terms of maintainability ?

Maybe we could be better off reusing the same tool, in this case detekt, than introducing a new one 🤔

Maybe we can split by parts.

This PR adds two things: Android Lint, and Compose checks for Android Lint.

Android Lint

Is the heavier guy here in terms of performance. Unlike Detekt, it will compile the code and check the compiler output for weird things. Because of that, it can analyse more stuff (like class structures) and even analyse resource files and catch localisation issues.

I believe adding Android Lint in general is beneficial. It just noticed we have 200+ localisation issues, for example.

Compose Checks for Android Lint

It's an extra check. By itself doesn't add much to verification time.

But continuing on your question: should it be on top of Detekt, or on top of Android Lint?

It seems some of these Detekt plugins rely on Detekt's Type Resolution, which we don't have set-up at the moment. And this would mean spinning up the Kotlin Compiler as well for Detekt, which we don't at the moment.
Some of them don't rely on that, so I'm not 100% sure they would be able to cover as much as the others.

The Detekt rulesets for Compose I found were not as popular and actively maintained as this Android Lint alternative by Slack. These aren't the only things to consider, but when selecting such a delicate topic, I'd go with the more commonly used tool.

[yamilmedina]

Thanks for the replies, it makes sense, just added another suggestion we might explore before merging, to see how much (if any) time could gain of execution

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[yamilmedina]

Coool 🚀

[github-actions]

APKs built during tests are available here. Scroll down to Artifacts!

[AndroidBob]

Build 4911 succeeded.

The build produced the following APK's:

• com.wire.android-v4.7.0(9742291)(9742291)-staging-compat.apk