-
-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
F-Droid inclusion #47
Comments
Hi @shuvashish76 thanx for suggesting this idea. However, I remember for once in the past I tried to search for docs for flutter specific and it was somewhat not able to clear my mind about how to ready a CI/CD like pipeline for flutter apps. Since it is easy to publish one APK but for continuous integration it was bit unclear to me (when I read about it few months ago.). |
ping @linsui for help |
See the template in https://gitlab.com/fdroid/fdroiddata/-/blob/master/templates/build-flutter.yml. We can extract the flutter version from https://github.com/HemantKArya/BloomeeTunes/blob/main/.github/workflows/main.yml#L25. |
Thank you so much @linsui it's great to have help from you. Since I am new to this, I want to ask that do i have to public my app signing keys in build file or is there any way to use them during build process using env keys? |
No, we don't use your key in any way.
|
https://gitlab.com/HemantKArya/fdroiddata/-/blob/master/metadata/ls.bloomee.musicplayer.yml |
The version name and version code should be extracted from https://github.com/HemantKArya/BloomeeTunes/blob/main/pubspec.yaml#L19, i.e.,
and please check the pubspec.lock file into the repo. |
i get it that you want the version code to be from BloomeeTunes/.github/workflows/main.yml Line 49 in 1af0475
and if use the build number again from 0 then when someone update the app it will say the app is either old or corrupted. So is there any way to you suggest for this scenario. Another doubt is that I sign my app with my own personal keys which are already saved at github workflow env, so they all are automatic built and released when new commits are pushed. How to replicate this pipeline. |
Then you can put the build number in a file published along with the apk so that we can extract it, e.g., build-number.txt. We sign the apk with out own key, or use your signature if reproducible build is enabled. See https://f-droid.org/docs/Reproducible_Builds/. |
Thanx you so much for replying @linsui, and the yml file: https://gitlab.com/HemantKArya/fdroiddata/-/blob/master/metadata/ls.bloomee.musicplayer.yml now the problem is
|
Do note that if you extract the signature, you need to upload it to fdroiddata manually for every version. If you use
Why not publish the splitted apks?
Yes.
We can do that in an MR. :) It still needs some midification. |
Okay then if put binaries link in yml file then it will automatically extract the signature from it, If I understood correctly.
because the splited variants have different build number basically it is intended behaviour added by Google itself in App Builder so that's why I wanted to use the default universal APK with default build number that is passed during building.
Thanx you so much 😊 @linsui. I will update my |
F-Droid supports split abi. You just need to change the version code scheme. See <https://github.com/nfcim/nfsee/blob/1302225df144a2747ecc8130bf43edee2440f1a4/android/app/build.gradle#L99> for example.
|
Thanx @linsui I just updated the release workflow changed the released apk abis to have same build number so now I can release the split-per-abi apks. https://github.com/HemantKArya/BloomeeTunes/releases/download/v2.9.12%2B141/build-number.txt can you have a check here and how to include the GitHub release binaries there automatically the latest's APK builds from release section. |
You can take a look at this example. :) |
So what if we make something like that |
VercodeOperation is used to calculate the version code from the number we extract. The binary url is calculated from the version code. So if the version code is 1411 then it can only use 1411. 🤷 |
So if you mean versioncode extracted from one of the APK generated by fdroid then it is fine cause I recently updated by build.gradle file (bc86121) to only use the |
When checking update, a number is extracted from upstream files. Then the version code for different abis are calculated according to VercodeOperation. These version codes are write to the metadata as versionCode. When building the apk, the url is calculated from versionCode in metadata. The number extracted from upstream files are not known when building the apk. |
I'm really sorry I just missed what you said especially -
so, what should I do for desired behaviour you suggest? |
Can you remove the build number from the tag name and the apk file name? |
If I am correctly getting you are saying to change the tags name from But that is Intended behaviour I made to track the versioning properly. Is there any no other working arounds? Without renaming those. |
You can also change the version name to |
okay then if i replace the name to from |
For every apk, there is a corresponding block in the metadata. The versionName and versionCode should match with the apk and are used to calculate the url of upstream apk. The checkupdates step doesn't care about the tag name. But when building the apk the url to the upstream apk needs to be calculated. If you change the version name to |
Ohhh..... |
If you set the version name as this then it works. :) |
you mean in this metadata yml file right? |
The versionName in the metadata should match the on in the apk. |
Please add the pubspec.lock in git. |
you mean here in github right? |
Yes. :) |
Is that all now 🙂. Will it be final after that or something else so that I can push it in next release. |
We need to build isar from source. You need to add a lock file for it. See immich-app/immich#12705 for example. |
H @linsui are all necessary steps are done, mean should I send a merge req to your official repo server? |
Please open an MR in https://gitlab.com/fdroid/fdroiddata/-/merge_requests, we can continue there. :) |
Hello, would you consider publishing the app on F-Droid please?
Documentation : https://gitlab.com/fdroid/fdroiddata/blob/master/CONTRIBUTING.md
The text was updated successfully, but these errors were encountered: