<div dir="ltr"><div dir="ltr">On Wed, Apr 28, 2021 at 12:21 PM Aleix Pol <<a href="mailto:aleixpol@kde.org">aleixpol@kde.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Apr 24, 2021 at 10:17 AM Volker Krause <<a href="mailto:vkrause@kde.org" target="_blank">vkrause@kde.org</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> with the Craft-based Android release package builds hopefully being close to<br>
> working, here are some thoughts on the next steps of getting those packages<br>
> into the corresponding app stores/repositories, and a few points I would need<br>
> help with.<br>
><br>
> (1) Signing<br>
> This should mostly be a copy/paste job from the existing setup for the nightly<br>
> builds.<br>
><br>
> (2) F-Droid Release Repository<br>
> On the Jenkins side this should also be mostly a copy/paste job, the nightly<br>
> build script for this will only need minor adjustments to be less aggressive<br>
> for expiring old packages.<br>
><br>
> We however would need to set up a new repository for release packages, next to<br>
> the one with the nightly builds. Ideally with a long-time stable URL so we can<br>
> maybe convince the F-Droid people to include that by default as an external<br>
> source (even if that means disabled by default as per their policy, still<br>
> better than not being available at all). That's probably something that would<br>
> need sysadmin help.<br>
><br>
> (3) Google Play<br>
> I would like to evaluate using fastlane supply (<a href="https://docs.fastlane.tools/" rel="noreferrer" target="_blank">https://docs.fastlane.tools/</a><br>
> actions/supply/) for automatically uploading metadata and APKs to Google Play.<br>
> That doesn't necessarily imply publishing APKs blindly, but being able to<br>
> automatically have APKs in the staging area as well as automatically syncing<br>
> translations for the app description seems very much worth it to me. And given<br>
> that fastlane actually defined the metadata format that F-Droid is using I<br>
> have high hopes that this integrates well with what we already have.<br>
><br>
> However, fastlane seems to be mainly distributed via Ruby's package manager,<br>
> not via regular distro packages. Is that a blocker for installing this on the<br>
> signing machine?<br>
><br>
> For testing, I'd also need an API access key for our Google Play account, as<br>
> described in the above link. I think that's something Aleix has to set up, I<br>
> don't have permissions for that.<br>
><br>
> This then presumably also needs a small driver script like we have for F-Droid<br>
> to upload new packages and metadata after signing.<br>
><br>
> Makes sense?<br>
<br>
The apks we generate now are already signed and can be just uploaded<br>
to F-Droid repos (our nightly repo being proof) and Google Play as is.<br>
So it's already done, unless you want to deviate from it in any way,<br>
but now it should work.<br></blockquote><div><br></div><div>The difference here from my understanding is that what we build now are nightlies, being built against the 'master' branch of a project.</div><div>Volker is targeting (from my understanding) builds from the actual stable releases (git tags / tarballs).</div><div><br></div><div>This is something that Craft is very well optimised for.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Regarding the usage of fastlane, we already support their format so<br>
yay. I don't know though how much we can extrapolate our generation<br>
through appstream. We might need ad-hoc solutions in some cases.<br>
<br>
In any case, big thumbs up, would be happy to help if there's anything<br>
I can help with.<br>
<br>
Cheers!<br>
Aleix<br></blockquote><div><br></div><div>Thanks,</div><div>Ben </div></div></div>