We need a strong link between the source repo URL and our buildserver. HTTP
redirects have a number of issues, and are unnecessary in our use case.
Once this is complete, then the buildserver can set http.followRedirects to
false, and we could also set the buildserver to fetch source over Tor to
avoid targetting it. Right now, gitlab.com only allows git fetches over
Tor if it is hitting a direct URL. gitlab.com/s redirect logic will
trigger Cloudflare captures otherwise.
* https://bugs.debian.org/79002
* https://www.debian.org/security/2019/dsa-4371
* https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-38000.html
* fdroidclient#1041
YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as
the default Loader is unsafe. Please read https://msg.pyyaml.org/load for
full details.
metadata/*/signatures/* are used for reproducible builds. If those files
change, then `fdroid build` should run and try to build the app with those
signature files. Also, `fdroid publish` needs to run to copy those
signature files to complete the test of reproducibility. Builds that use
the `Binaries:` method are already verified as part of `fdroid build`.
fdroidserver!893
fdroidserver#891
fdroiddata!8816
This looks through all open merge requests to see if issuebo has run on
them yet. If a merge request needs an issuebot review, this will send the
trigger to start the job on fdroid/fdroiddata per merge request.
This uses @uniqx's awesome new 'plugin' feature to create a 'fetchsrclibs`
command. The 'fdroid build' gitlab-ci job uses --on-server, which does not
set up the srclibs. This plugin does the missing setup.
This should hopefully provide reliable triggering for issuebot on merge
requests. Before, detecting the merge request number was happening on the
receiving side, and it had weird issues.
This then edits the metadata file for apps with failing git repos, then
includes those edited files in the gitlab job artifacts.
fdroid/fdroiddata!5262
I wrote this nearly a year ago, and it's recently been broken by the new
redirect that Google Code does. A few dozen apps were fixed thanks to
this, so it did its job.
If any devs still on Google Code after all this time want to update
their metadata, they can.
This avoids calling rewritemeta separately, which means parsing all the
metadata files once instead of twice.
This reduces the running time of the pre-commit script from ~3s to ~2s
on my machine.