ci: Create internal release on every commit

[M123-dev]

What

@teolemon

• now we create a new internal build to org.openfoodfacts.scanner on every commit, later to be changed to the new internal listing.
• One problem occurs while doing it like that. in the store consoles we have no way to differentiate between builds intended for internal or release candidates.
• My suggestion would be to push versions published by release-please to the beta branch and only promote those ones.
• Edit: This would allow to quickly see the latest changes without creating a new GitHub release (and new release name) nearly every day

Part of

• Distributing the app widely (tracker) #2515

[AshAman999]

Not an expert, but I guess it's too much, even for alpha or internal a new release on every merged pr is too much.
If we could do one in a week or a day.
Comments ?

[monsieurtanuki]

The question asked here is: how much can we delegate to automatic processes?

If the idea is: "we want a full release process after each merged PR", that makes sense if you want a systematic automatic check of all the boring tiny details about a release.

But doing so we lose track (and interest) about the releases.

I prefer the semi-automatic release process as in off-dart: it's automatic because all the PR are included and all the release process is automatic (which is great), but WE decide when to trigger a release, that can be labeled "offline tasks + vertical buttons + new crop tool" (and not just "btw some random developer merged a PR 10 minutes ago").

[teolemon]

@monsieurtanuki It's not a real release, it's internal to ensure we can test continuously.
Promotion to beta and stable are still manual, conscious decisions

[M123-dev]

The plan is to eventually have two playstore listings:

1. The main listing
2. A secondary listing only with the internal lane for us devs to test so that we can have two versions on our phone at the same time.

I only added this change before creating a second listing as I noticed that we have a LOT of release please releases lately. This isn't a problem but I think it's overkill to have the release PR merged + a github release + a new release PR sometimes twice a day

[codecov-commenter]

Codecov Report

Merging #2983 (d3bce79) into develop (396822b) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           develop   #2983   +/-   ##
=======================================
  Coverage     6.49%   6.49%           
=======================================
  Files          246     246           
  Lines        12132   12132           
=======================================
  Hits           788     788           
  Misses       11344   11344           

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[VaiTon]

@M123-dev Thank you!