<div dir="ltr"><div dir="ltr">On Wed, Apr 28, 2021 at 7:29 PM Volker Krause <<a href="mailto:vkrause@kde.org">vkrause@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 Wednesday, 28 April 2021 02:20:51 CEST Aleix Pol wrote:<br>
> 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>
> > Hi,<br>
> > <br>
> > with the Craft-based Android release package builds hopefully being close<br>
> > to working, here are some thoughts on the next steps of getting those<br>
> > packages into the corresponding app stores/repositories, and a few points<br>
> > I would need help with.<br>
> > <br>
> > (1) Signing<br>
> > This should mostly be a copy/paste job from the existing setup for the<br>
> > nightly builds.<br>
> > <br>
> > (2) F-Droid Release Repository<br>
> > On the Jenkins side this should also be mostly a copy/paste job, the<br>
> > nightly build script for this will only need minor adjustments to be less<br>
> > aggressive for expiring old packages.<br>
> > <br>
> > We however would need to set up a new repository for release packages,<br>
> > next to the one with the nightly builds. Ideally with a long-time stable<br>
> > URL so we can maybe convince the F-Droid people to include that by<br>
> > default as an external source (even if that means disabled by default as<br>
> > per their policy, still better than not being available at all). That's<br>
> > probably something that would need sysadmin help.<br>
> > <br>
> > (3) Google Play<br>
> > I would like to evaluate using fastlane supply<br>
> > (<a href="https://docs.fastlane.tools/" rel="noreferrer" target="_blank">https://docs.fastlane.tools/</a> actions/supply/) for automatically<br>
> > uploading metadata and APKs to Google Play. That doesn't necessarily<br>
> > imply publishing APKs blindly, but being able to automatically have APKs<br>
> > in the staging area as well as automatically syncing translations for the<br>
> > app description seems very much worth it to me. And given that fastlane<br>
> > actually defined the metadata format that F-Droid is using I have high<br>
> > hopes that this integrates well with what we already have.<br>
> > <br>
> > However, fastlane seems to be mainly distributed via Ruby's package<br>
> > manager, not via regular distro packages. Is that a blocker for<br>
> > installing this on the signing machine?<br>
> > <br>
> > For testing, I'd also need an API access key for our Google Play account,<br>
> > as described in the above link. I think that's something Aleix has to set<br>
> > up, I don't have permissions for that.<br>
> > <br>
> > This then presumably also needs a small driver script like we have for<br>
> > F-Droid 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>
<br>
For the release builds signing is still missing, but that is just one small MR <br>
away I think: <a href="https://invent.kde.org/sysadmin/binary-factory-tooling/-/merge_requests/173" rel="noreferrer" target="_blank">https://invent.kde.org/sysadmin/binary-factory-tooling/-/<br>
merge_requests/173</a></blockquote><div><br></div><div>Oops, apologies for missing your fix there - i've had quite a bit of email lately.</div><div>That has now been merged in and deployed to the Binary Factory.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<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>
The existing generator already allows for manual overrides by preferring <br>
existing fastlane metadata in the source dir over generating it from <br>
appstream. That's e.g. how we get Itinerary's store header image in there, or <br>
KTrip's Android specific screenshots. Ultimately you can entirely replace that <br>
mechanism when needed, binary factory just wants fastlane metadata as part of <br>
the build results, how it gets there doesn't matter.<br>
<br>
> In any case, big thumbs up, would be happy to help if there's anything<br>
> I can help with.<br>
<br>
You can indeed help :) Please go through the setup instructions for Google <br>
Play API access (<a href="https://docs.fastlane.tools/actions/supply/#setup" rel="noreferrer" target="_blank">https://docs.fastlane.tools/actions/supply/#setup</a>) and send <br>
me the resulting key, so I can test the fastlane integration. My access rights <br>
aren't sufficient to do this myself.<br>
<br>
Thank you,<br>
Volker</blockquote><div><br></div><div>Regards,</div><div>Ben </div></div></div>