fix: make lint work

[hannesa2]

Fix one issue from #4686
But there are still more lint errors !

This one is gone:

[hannesa2]

As you can see, the action "Android Instrumented Data Tests" is still working properly

[hannesa2]

Btw, as you use several runner at the same time (here it waits > 24 minutes), I would merge "Validate Gradle Wrapper" into "Detekt" this would not extend the runtime of the job and you save at least one runner.

[jesmrec]

@hannesa2 thanks for the contribution, we'll take a look asap.

[jesmrec]

We'll merge this PR when we finish our work in the current release 4.8.1. Thanks again!!! also, i'd like @joragua to take a look as well.

About CI: gradle wrapper validation is a 10-secs-job, it should not abuse of the runner usage 😆 . You @hannesa2 unfortunately suffered the overload of some days ago, but that's not the rule.

About Lint: we are trusting Detekt as you noticed. I know that's not the same as Lint... the point is: to make Lint useful, we have either to fix all the reports beforehand, or set a baseline (that means, ignoring existing reports and only marking the new ones). At this point, i don't find any of those solutions are good at this point. If i'd have to go for one option, i'd take the baseline... all ideas and inputs are welcome.

Finally, for further PRs, it'd be cool that the name of the branch follow our convention. Some of the CI jobs depend on the branch prefix to execute: feature/, fix/, technical/, improvement/

[joragua]

Hi @hannesa2! Thanks for opening this PR! 🍻

There are some topics here to comment:

1. CI system: as @jesmrec mentioned in the comment above, the CI system sometimes collapses or breaks due to a overload from other repositories in the organization. The runner was busy and the workflows were queued so, I'd not modify the current workflows... (it depends on the day) 🤔

2. Lint: We are not taking his analyzer into account at the moment because we are using Detekt. There are a lot of warnings but they would likely require more changes to be fixed and we would need to check whether something in the app is broken after those changes. Right now, we have other priorities in the app (such as security issues and other interesting features). Anyway, feel free to fix any warning that you want (like you did in this PR). IMO (as Jesús also mentioned) I'd set a baseline from now on, review all new warnings, but not spend too much time fixing the existing ones.

3. PR conventions: Do not forget to read the guidelines in CONTRIBUTING.md. Branches must include one of the required prefixes because some workflows depend on the branch name. Commits must be GPG/PGP signed, and it'd be great if each commit include a descriptive name (refactor: remove debug variant manifest) and a Signed-off-by line. If you have any doubts, let us know and we'll be happy to help you! 😄

Thanks a lot!