*** Preliminary steps
First, make sure you have a gitea token. You can create one here: https://git.libreschool.org/user/settings/applications
Clone the repo. We’ll start with drone on your private repo.
*** Setup drone on your forked repo
Go to https://drone.libreschool.org ang login with your git credentials (the same that you use for git.libreschool.org).
Open the “hamburger menu” on the top right corner and choose “Repositories”; if you don’t see the newly created repo, in the same menu you can choose “Synchronize”.
You can now enable each single repo; after enabling, take a look inside: you’ll be greeted with an empty “build list”.
Next step is to go to repo settings inside drone and enable ALL the repository hooks (push, pull, tag, deployment).
Now go to repo secrets and add a secret named “gitea_token” with the token you created before.
If yuo plan to add a signature to the package (which is always a good idea), you have to add two more secrets: gpg_key and passphrase.
It’s now time to add a .drone.yml file.
*** .drone.yml
Add to your repo a .drone.yml file, taking one from another repo with the same destination (libreschool server vs client). It’s better if you use another branch.
As soon as you push the commit, a build should start; if something goes wring, you can take a look at the build log in drone.
Usually the .drone.yml file is not ok on the first try 
That’s why you have a branch and you make some tests…
When the build is OK, do a “git tag” and push the tag also. This will create a gitea release, and drone will add the cmopiled packages.
Try if this works. You can use a “test” tag, and you can delete it if everything is OK (just make sure to delete the corresponding gitea release also)
*** reflect changes to main repo
Now that you have a perfectly working .drone.yml file, in a separate branch, on your forked repo, you can open a PR to push these changes to the main repo.
If you are an admin, make sure that drone is enabled in for the upstream repo and all the hooks and secrets are set.
When the PR is accepted, a new build is made. Push a tag (corresponding to the package version) on the upstream repo to trigger a release.
Now you can remove the branch.