search

SankethBK / diaryvault

A personal diary application written in Flutter
https://play.google.com/store/apps/details?id=me.sankethbk.dairyapp
MIT License
86 stars 59 forks source link

initial fastlane structures #89

Closed IzzySoft closed 10 months ago

IzzySoft commented 11 months ago

What type of PR is this? (check all applicable)

Description

Your Fastlane "starter package" as discussed in #70. Be welcome to use my Fastlane Cheat Sheet to build on this (e.g. adding per-release changelogs), and take care for the limits (e.g. max 80 chars for shortdesc, max 4.000 for fulldesc, max 500 for per-release changelogs).

Note that for fulldesc I used full HTML compressed to a single line. This is for 2 reasons: formatting looks better, and "no linebreaks" prevents F-Droid from converting each \n into a <br> (yes, it does that) making it look … well, less good :see_no_evil:

Featured Covered in this PR

Related Tickets & Documents

Screenshots, Recordings

Part of the PR :see_no_evil:

Tested Feature??

SankethBK commented 10 months ago

Hi, sorry for the delay and thank you for helping us to onboard our app to your repository, we've been receiving good traffic (we got almost 30 users in just 1 week). I went through the guide you shared for onboarding the app to F-Droid. I read about reproducible builds and how F-Droid ensures all libraries are open source. I've got a couple of questions related to the same:

  1. The code in my master branch is not compatible with F-Droid guidelines as it uses googleapis, I have created a separate branch foss-master which is migrated to Appwrite. So while raising issue in F-Droid repo for generating <applicationId>.yml is there a way to specify to use foss-master branch instead of master for reproducible builds?
  2. I understand fastlane is used for updating description and screenshots without generating merge request everytime. I went through this setup docs, but couldn't find how to link fastlane to deploy to F-Droid. Also do we need to just add this github action and does F-Droid automatically creates fastlane pipeline for our app based on the fastlane folder structure we have (I saw some CI/CD checks were running in gitlab issues eg ) or do we have to setup fastlane pipelines individually?
IzzySoft commented 10 months ago

Glad to read your happy with the listing! Let me help with your questions as well:

  1. best practice is using build flavors for that. You cannot specify branches for F-Droid – F-Droid goes by tags/commits. That means you could take care for that via those, e.g. creating tags (and releases) with names like foss-<versionName> (to make them clearly recognizable; keep the prefix constant and use it only for those) and point them to a commit inside that branch.
  2. you don't need to link fastlane to anything. If you have it in one of the 3 standard locations (as this PR does), Fastlane is detected automatically.
SankethBK commented 10 months ago

Thank you! I'll plan to submit an issue to F-Droid repo by today

IzzySoft commented 10 months ago

I'll plan to submit an issue to F-Droid repo by today

I'd suggest to consider the order of tasks. If you start that before having this PR merged, issuebot will complain about Fastlane being amiss :wink:

SankethBK commented 10 months ago

I'll plan to submit an issue to F-Droid repo by today

I'd suggest to consider the order of tasks. If you start that before having this PR merged, issuebot will complain about Fastlane being amiss 😉

Got it, I'll make sure to merge this PR. I have one more question, I have some credentials in .env file, I have just added placeholder values in GitHub and have actual values in my local. Will it affect the reproducible builds in anyway (because apk built in my local will have actual credentials and one from GitHub will have dummy values)?

IzzySoft commented 10 months ago

Will it affect the reproducible builds in anyway (because apk built in my local will have actual credentials and one from GitHub will have dummy values)?

Sure that will affect it. For RB to succeed, the resulting APKs (yours and F-Droid's) must be identical (except for the signature of course). You can get it working nevertheless by providing corresponding APKs in addition to the other one (like, fdroid_build_*.apk) at the releases, should the ones currently attached be those with "actual credentials".

SankethBK commented 10 months ago

Will it affect the reproducible builds in anyway (because apk built in my local will have actual credentials and one from GitHub will have dummy values)?

Sure that will affect it. For RB to succeed, the resulting APKs (yours and F-Droid's) must be identical (except for the signature of course). You can get it working nevertheless by providing corresponding APKs in addition to the other one (like, fdroid_build_*.apk) at the releases, should the ones currently attached be those with "actual credentials".

So the APK with fdroid_build_*.apk will have dummy credentials and used for validating RB, and other APK (let's say fdroid_release*.apk) will be used for releasing, is my understanding correct?

IzzySoft commented 10 months ago

Only the first part. The very same ones used for validating RB would be used for releasing. We can only release what was validated. The others would then be "additional download options at Github".

Just wondering what you're aiming at: Would the app work without proper credentials – or could the one built with "dummy credentials" not be used? What credentials we're talking about anyway?

SankethBK commented 10 months ago

Currently, I have a Dropbox OAuth password. Its essential for the app to work properly. I believe it's not a sensitive credential and it would be exposed in the APK binary after the compilation anyway. But I think its not best practice to expose it in public repos as it can be used to impersonate other apps.

I will add a proxy server to fetch these credentials instead of storing them in code, so that RB's can produce same result

IzzySoft commented 10 months ago

You could provide a configuration option for that, so whoever wants to use it could provide their own credentials. That would entirely solve that problem (that's what comparable projects did in this case).

SankethBK commented 10 months ago

Yeah, currently they still need to login to their Dropbox account with their own creds. But setting up the Dropbox Oauth app with right permissions might be a bit tedious, but we can use this for NextCloud which only requires a username and password for authenticationnstead of access tokens. I am working on setting up a proxy server for this, I will update by today.

IzzySoft commented 10 months ago

Thanks! Updated the config for your app on my end, so Fastlane will be pulled along with new releases from now on.