Always run lint when running debug builds

[Luna712]

No description provided.

[diogob003]

As far as I know we do have 4 "flavors"

• Green 🟢 com.lagradost.cloudstream3.prerelease.debug
• Red 🔴 com.lagradost.cloudstream3.prerelease
• Green 🟢 com.lagradost.cloudstream3.debug
• Blue 🔵 com.lagradost.cloudstream3

If I'm not mistaken, the default variant for Android Studio is com.lagradost.cloudstream3.debug and the variant used on pr build is com.lagradost.cloudstream3.prerelease.debug

It might be worthwhile to include lint checking in both debugging variants, so that the developer can find and fix bugs before submitting a pull request.

[Luna712]

As far as I know we do have 4 "flavors"

• Green 🟢 com.lagradost.cloudstream3.prerelease.debug
• Red 🔴 com.lagradost.cloudstream3.prerelease
• Green 🟢 com.lagradost.cloudstream3.debug
• Blue 🔵 com.lagradost.cloudstream3

If I'm not mistaken, the default variant for Android Studio is com.lagradost.cloudstream3.debug and the variant used on pr build is com.lagradost.cloudstream3.prerelease.debug

It might be worthwhile to include lint checking in both debugging variants, so that the developer can find and fix bugs before submitting a pull request.

Good idea, I missed that part. It is now done.

[Luna712]

For the record I did it like this with androidComponents instead of checking both assemblePrereleaseDebug and assembleStableDebug just because 1) this seemed cleaner to me, 2) is more future proofed if we add some other flavor at some point or something, and 3) is more designed for circumstances like this.

[Luna712]

As far as I know we do have 4 "flavors"

• Green 🟢 com.lagradost.cloudstream3.prerelease.debug
• Red 🔴 com.lagradost.cloudstream3.prerelease
• Green 🟢 com.lagradost.cloudstream3.debug
• Blue 🔵 com.lagradost.cloudstream3

If I'm not mistaken, the default variant for Android Studio is com.lagradost.cloudstream3.debug and the variant used on pr build is com.lagradost.cloudstream3.prerelease.debug

It might be worthwhile to include lint checking in both debugging variants, so that the developer can find and fix bugs before submitting a pull request.

@diogob003

Just a small correction here though, we technically only have 2 "flavors" (stable and prerelease) and 2 build types, release and debug. That means that for both flavors, can have the combination of any of the build type, stableDebug, prereleaseDebug, stableRelease, prereleaseRelease, what I forgot was for some reason, android studio builds stableRelease by default, and didn't consider that one, which ironically was the entire point of this PR to work locally the same as PRs here, as otherwise we could just add lint to the workflow to achieve the same thing.

[Luna712]

@fire-light42 sorry for ping but any chance this can be merged so that #2356 can be merged? So that we make sure that no other error level issue is introduced in between which would cause build failure if so.

[fire-light42]

While I want to merge #2356 and keep errors out of main I think this is the wrong strategy.

The lint check is simply too long to use on debug builds. On small incremental builds (one line changes in kotlin) I still measured large lint check times, larger than the build times.

I think checking lint on the pull request and pre-release builds would accomplish the same goal without wasting any time. What do you think @Luna712 ?

[Luna712]

While I want to merge #2356 and keep errors out of main I think this is the wrong strategy.

The lint check is simply too long to use on debug builds. On small incremental builds (one line changes in kotlin) I still measured large lint check times, larger than the build times.

I think checking lint on the pull request and pre-release builds would accomplish the same goal without wasting any time. What do you think @Luna712 ?

Probably a good idea. I'll update this soon.

[Luna712]

@fire-light42 I reopened #2358 to switch back to that original method which I originally was going to do.