initial fastlane structures from IzzyOnDroid#29
initial fastlane structures from IzzyOnDroid#29IzzySoft wants to merge 1 commit intowarren-bank:servicefrom
Conversation
|
Oof. I just notice we're having 3 apps here, and need a slightly different app description. How do you wish to deal with that? At IzzyOnDroid, we're flexible, and can define any "root location" for it. F-Droid would be less flexible, and need it in one of 3 specific locations:
Given your repo structure, none of those would fit. For IoD, we could but it inside the app specific directories inside |
|
@warren-bank any word? Sending some motivation, this time as graphic from our stats. Each download implies an install, as the view was restricted to F-Droid clients:
So more than 100 monthly installs just for |
|
I'm leaning heavily towards "no".. because I hate clutter, and this feels like a lot of extra clutter. Is there any support for hosting these files in a separate git repo? For example, I already have a single git repo that contains everything pertaining to my self-hosted f-droid repos.. which I don't update nearly as often as I should. In any case, this git branch contains the f-droid metadata for all of my apps. Unfortunately, the conventions used by f-droid seem to differ slightly from fastlane, which is annoying. But if you can pull fastlane data from a git repo that is separate from the git repo used for the source code, then I'd be willing to write a migration script. |
Only if that git repo then is added as submodule to the app's repo. Fastlane is processed locally here, from a clone of the app's repo (which is checked out with all its submodules, if there are any).
One directory per app would work then (we support custom fastlane locations inside the app's repo). That directory could e.g. be the corresponding app's packageName, and the rest of the structure simplified:
Ah! That would work as well, if it were availabe as git submodule in the app's repo. I haven't worked much with submodules, but if it's possible and you wanted to, you could "mount" the corresponding app dir as Would that work for you? It would for us – and we probably can simply close all the PRs I've opened for fastlane on your apps (or you could pick from them what you feel useful). PS: the fastlane trees must have a PPS: digging deeper into the structures, I guess we need that migration you were speaking of: they are no fastlane structures 🙈 |
|
I didn't think you'd be able to reference the fastlane metadata from another repo.. but I had to ask :) In any case, there's absolutely no way that I'd include that entire git repo of f-droid metadata as a submodule in every project; it's enormous, and nobody would appreciate that. What is the downside of opting out? I understand that including fastlane metadata in my repos would allow me to customize the apps' descriptions in your f-droid repo. But I'm not very interested in that.. your descriptions seem good.. heck, probably more informative than I'd be :) So, would it be a problem for you if I choose to leave well enough alone? Because.. I really have no intention of adding extraneous files to any of my git repos. |
Sure! And you're not that far off with that. We supported that in the past, when we used to sync fastlane "online" by utilizing the corresponding forge's API. But that was taking ages, and we ran into "API limits" far too often (despite of having tokens). For example, our monthly quality check (cross-checking whether repos were still there, open, had fastlane added/dropped, new fastlane features added, etc) was taking more than 13h to complete, and missed several items due to API limit shenanigans. Having moved the fastlane part to local clones, it now is through in less than half an hour – and uses far less resources (we try to be as "green" as possible, too)…
That any updates you think needed (screenshots to replace, features added/dropped needing an update to the description, etc), would require you to open an issue with us – and us then to perform manual actions, eating time on both ends we could otherwise invest into other things (our current task list is longer than the Amazon river – or at least feels that way; so see just a part of it, take a look here). We have about 1.3k apps to cover. So the more automation, the better.
Not only there. For apps available at f-droid.org, they'd be synchronized automatically as well (i.e. affect the listing there).
Thanks! 🤗 You're welcome to adopt them if you wish – be it via these PRs, or by simply copy-pasting 😉
Well, they run the risk of becoming outdated (I've opened hundreds of similar PRs, upstreaming our metadata, and had that case more than once: "those graphics are outdated, could you use the newer ones" / "I've updated the description, it was no longer fully correct" / …). We cannot manually watch-and-keep-updated those metadata for all the apps we cater for. TL;DR: they'd be rather static, and require manual actions from both (you and us) to be updated – while with the metadata in the app's repo, you could simply update+commit+push, and they'd be automatically synced here when the next release is being pulled in. We prefer them in the app's repo – so "highly recommended", but not exactly mandatory. |
|
I'm good with static details.. The overview of my apps never change; each app sets out to do one thing. |
|
OK, then I'll mark them to be kept as "local metadata" here. Just to make sure: can you please go over the PRs I've opened with your apps to ship fastlane, and see if all's good? Then close them each, which I then take as signal "all fine, mark local". And should there be something that needs to be adjusted, just leave a comment with the closure? |

this PR provides you with a "fastlane starter package" – to give it into your hands to define how your app is presented, and make it easy to keep descriptions & graphics in sync with your development. Some notes to sum them up in a place easy to find for you:
full_description.txtmax 4,000 chars, graphics must have specific aspect ratios etc.full_description.txthere I've used HTML compressed into a single line, to prevent the fdroid software converting each line break to a<br>. The tags used for this are supported by F-Droid.org as well, and to my knowledge even by PlayStore.And now: Enjoy!