jackBonadies / SeekerAndroid

Android client for the Soulseek peer-to-peer network
GNU General Public License v3.0
247 stars 4 forks source link

Host your own F-Droid repo on GitHub Pages #22

Closed julianfairfax closed 2 years ago

julianfairfax commented 2 years ago

As mentioned in https://gitlab.com/fdroid/wiki/-/wikis/Inclusion-of-Xamarin-(.NET)-apps, Xamarin apps will most likely never be compatible with F-Droid's official repo. However, it's very easy to set up your own on GitHub Pages, using this template https://github.com/bitwarden/mobile/blob/master/.github/workflows/release.yml#L93...L175.

I know your app is already included on a third-party repo, but it's better for user trust, and for your own updating, if you can directly host your own repo on GitHub Pages, completely free of charge. This is what Bitwarden has done for their application, and it allows to have greater control of their releases than even the official F-Droid repo.

jackBonadies commented 2 years ago

This looks promising. Not familiar with github pages but I will look into this.

Efreak commented 2 years ago

I set up a GitHub action in April that pulls apk files from here and creates an fdroid repo, completely automated. You can find it here. If you want to add it to this repo, I'd suggest modifying it to run after release rather than every hour, and to work on a separate branch.

julianfairfax commented 2 years ago

I set up a GitHub action in April that pulls apk files from here and creates an fdroid repo, completely automated. You can find it here. If you want to add it to this repo, I'd suggest modifying it to run after release rather than every hour, and to work on a separate branch.

Amazing. It should have the non-free net anti-feature btw.

Efreak commented 2 years ago

Amazing. It should have the non-free net anti-feature btw.

Done. I copied the metadata from izzyondroid, so it's got the issue link and others now too. If you[1] want, I can send the repo over to you; in the meantime I've given you access to the repo (I used Seeker to figure the action out, was thinking of using it for other apps, but tbh izzyondroid has most of what I need anyways)

[1]: edit: this is what I get for not looking at who says things. I thought you were @jackBonadies . I've given him access, and San willing to transfer ownership to him.

julianfairfax commented 2 years ago

Amazing. It should have the non-free net anti-feature btw.

Done. I copied the metadata from izzyondroid, so it's got the issue link and others now too. If you[1] want, I can send the repo over to you; in the meantime I've given you access to the repo (I used Seeker to figure the action out, was thinking of using it for other apps, but tbh izzyondroid has most of what I need anyways)

It should only have non-free net, not non-free dep. The non-free dep issue has been fixed.

Efreak commented 2 years ago

@jackBonadies: I've submitted a request to transfer the repo. if you're willing, let me know and I'll update the URLs and the config.yml first, and update the action to run on releases, not on a schedule.

jackBonadies commented 2 years ago

Sounds good. Thank you for your work on this :) I am not too familiar with hosting an fdroid repo. Sorry I am a bit behind on this. Please let me know if there is anything I should do once establishing ownership of the repo, as, other than having it run on releases as opposed to schedule, it seems to be complete. The only thing I will do is add a link in this repo's readme so that people can find it easier.

Efreak commented 2 years ago

Actually, I'm not quite sure that will work the way I expected it to. Instead, you should pull my repo into yours in a second branch. This will keep the action in the same repo, which will simplify things (the only other way to have a release cause an action is with a webhook, which would require two actions).

  1. Generate a personal access token with (at least) the repo scope and no expiration and add it as a secret with the name GH_ACCESS_TOKEN

  2. Add keystore and config.yml secrets to the repo. Whichever you choose, this should happen before the new branch is imported. There's three options here:

  3. Add the new branch to your repo. Again, two options here:

    • Add a new branch to your repo via command line (github web interface doesn't allow creating orphan branches, adding branches from unrelated repos, or adding new branches via pull request)
    • Alternatively, I can do it for you if you add me as a collaborator to this repo. That shouldn't be necessary though.
commands for 3a ``` git remote add efreak https://github.com/Efreak/SeekerAndroid` git fetch efreak git checkout efreak/fdroid git branch fdroid git push --set-upstream origin fdroid git remote remove efreak ```
jackBonadies commented 2 years ago

For step 2 I am a bit confused on the keystore and config.yml secrets. I generated them using fdroid init. What are these keys? I can use my keys instead of the ones that you used to create the repo? Or would I need yours if I plan on adding your branch? Also your repo has apk files embedded in it. Is there a way to have it point to the github releases?

Efreak commented 2 years ago

The keys are used for signing the index, which contains hashes (and also for signing apps if you build them via fdroid, I think, but I've never done that).

Fdroid generally expects a repo to be in a parent directory called fdroid with child directories of repo and archive (optional, not used here). The apk files are expected to be in the child directories. It's possible to use child directories with other names, however the apk files still need to ask be in the same directory. Thus, you can't use GitHub releases. It's possible to use other CDNs to deliver the files, however the directory structure still needs to be intact, as fdroid doesn't support http redirects (neither does GitHub pages for that matter)

My keys are only needed if you don't have an environment you can easily generate them; I've had problems making assumptions about developers being able to use Linux/cli/scripts/python in the past, and didn't want to make any assumptions.

Efreak commented 2 years ago

I've updated the repo urls, qrcode and readme. You can pull from efreak/SeekerAndroid fdroid branch at any time. The following keys should be the only contents of config.yml, as I've updated it to make it easier to modify the not-secret parts of config.yml by appending secrets

lines to keep from config.yml When creating the secrets for the repo, only keep the following lines in your local config.yml before encoding the file with base64. The rest of the lines are already there. ``` gpgkey repo_keyalias repo_pubkey keystore keystorepass keypass ```

If you update the secrets, then import my branch, it should build immediately, and be ready/working within minutes.

jackBonadies commented 2 years ago

I updated my config.yml to only have those lines uncommented and added it as a secret. I then added the 'fdroid' branch. I am still new to github workflows, however, so I am not sure what I should be expecting or if I have set things up correctly.

Efreak commented 2 years ago

Edit: You'll need to move the workflow to the default branch (the branch you base your releases on). It won't work in the fdroid branch. Unless you want the archives for your releases to be fdroid repos instead of source code. Open the collapsed message at the bottom of this post for my annoyances.

You can either import the workflow file from my branch yourself, or you can

The workflow is configured to only run automatically on release, but is configured to allow manual runs.

You can trigger a manual run by

  1. Accept my pull request (#23) or set up a blank trigger with the same name in master yourself.
  2. Go to the actions tab and selecting the workflow named Generate F-Droid Repo (here's a direct link, since your action has the same name as mine. Edit: this will only work after step 0)
screenshot ![screenshot](https://i.imgur.com/0mWcTf0.png)
  1. Click Run Workflow, and the green Run Workflow button.
    screenshot

screenshot

  1. It'll take up to a few minutes to get started, and a few minutes to run the task. Assuming the setup is correct (I didn't bother with fully configuring this fork, so I can't test it), you should have a working fdroid repo in under 10 minutes.

I can't get the workflow defined in the fdroid branch to keep the logic with the code > This started out quite simple until I tried to take a screenshots and realized that my actions tab shows no actions available. I've tried a whole bunch of stuff and figured out: 1. If I create a `workflow1` in the fdroid branch, it doesn't show up in the actions tab (by name) 2. if I create a `workflow1` in the default branch, it shows up (by name) 3. If I create a `workflow1` with the same name in both branches, it shows up correctly (by name) and allows me to choose which branch I want to run it in. 4. If I create a `workflow1` in the default branch and a `workflow2` in the fdroid branch, the actions tab shows `workflow1` and `.github/workflows/workflow2`. It shows the path for workflow2, rather than the name, though IIRC the workflow worked correctly 5. I can't get automated on:release actions to run from another branch *no matter what I do*. - I think you might need to create your release from the branch you want the action to run on. In other words, if you create the workflow in the fdroid branch, it might *only* run when you release from the fdroid branch. See [Triggering a workflow](https://docs.github.com/en/actions/using-workflows/triggering-a-workflow) (*GitHub searches the .github/workflows directory in your repository for workflow files that are present in the associated commit SHA or Git ref of the event.*) - I didn't bother to test this, because I don't want releases containing an fdroid repository instead of source code 6. I didn't know any of this until now because until now I've never tried using the release trigger, or working with a repository of source code (so far I've only used actions for releases from other repos, and the default branch has been the one with the repo)
julianfairfax commented 2 years ago

Amazing. It should have the non-free net anti-feature btw.

Done. I copied the metadata from izzyondroid, so it's got the issue link and others now too. If you[1] want, I can send the repo over to you; in the meantime I've given you access to the repo (I used Seeker to figure the action out, was thinking of using it for other apps, but tbh izzyondroid has most of what I need anyways)

It should only have non-free net, not non-free dep. The non-free dep issue has been fixed.

@Efreak I guess it's too late for you to do that now, but unless I'm wrong this should be removed

Edit: Done

jackBonadies commented 2 years ago

I was able to successfully run the action! commit https://github.com/jackBonadies/SeekerAndroid/commit/69a6586e168c459836be368b4423f1adacecb969 looks like it did replace the styled qrcode with the default one and it also added the 4th and 5th most recent .apks (for 5 total), but overall seems to have worked nicely.

julianfairfax commented 2 years ago

I was able to successfully run the action! commit https://github.com/jackBonadies/SeekerAndroid/commit/69a6586e168c459836be368b4423f1adacecb969 looks like it did replace the styled qrcode with the default one and it also added the 4th and 5th most recent .apks (for 5 total), but overall seems to have worked nicely.

It works! The link is https://raw.githubusercontent.com/jackBonadies/SeekerAndroid/fdroid/fdroid/repo?fingerprint=D9613C106A63D632F0F15597F4A91C276D3C6ED152F19518C3A5573BF8DA2375

You should put that link in the README and then close this issue

Also the non-free dep anti-feature should be removed from this repo like it was from the other.

julianfairfax commented 2 years ago

@jackBonadies Shouldn't the non-free dep anti-feature should be removed from this repo? As far as I understand the F-Droid version doesn't require Google Play Services.

jackBonadies commented 2 years ago

@julianfairfax thanks, I have removed it now