GitLab CI runs the Docker images in a way that makes it not a login shell.
Files in /etc/profile.d are only sourced automatically in a login shell,
so it needs to happen manually here.
git diff A...B is equivalent to git diff $(git merge-base A B) B.
See man git-diff.
In some special situations `git merge-base A B` fails with "fatal: FETCH_HEAD...HEAD: no merge base".
This test script was effectively not running anyway because nothing was
cloning the git repo for it to run on. `fdroid build` will end up cloning
the source, so it makes sense to run this script after that process.
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.
The use of rules: in 'fdroid build' seems to break the triggering of
'lint' and 'trigger-issuebot' and makes merge requests into "Detached
merge request pipelines". This syncs the triggering setup between 'lint',
'fdroid build', and 'trigger-issuebot'.
The only/except rules in all the jobs are quite complicated between
lint, fdroid build, issuebot, and checkupdates. It seems that issuebot
never gets triggered on most merge requests, with most of the time, the
job isn't even started. The special 'merge_requests' rule comes with all
sorts of complicated caveats, so hopefully this simpler setup works.
GNU parallels in Debian is 4 years out of date, missing about 40
releases and not updated in sid either.
The version in Debian claims to support the -X option for
splitting arguments in $jobs buckets but generates completely bogus jobs,
where the first job contains something like 80% of all arguments and the
other jobs contain much less.
It also generates 11 jobs when we asked for 10... :-/.
Also simplify the setup further by using parallel's {/.} replacement
pattern, which strips leading path's and extensions instead of bash
pattern substitution magic.
Previously we limited the number of arguments for each job, but this
meant we outgrow our current concurrency value.
The `-X` argument makes parallel split all arguments between the 10 jobs
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 be run on all branches in forks and all merge requests, as
long as they change a metadata file. Unfortunately gitlab-ci's "changes"
logic is not as sophisticated as the logic written in the job for detecting
which files changed. gitlab-ci's logic only detects changes that happened
in the current push event, this job's logic compares to master.
Using gitlab-ci's "changes" logic means that if someone changed a metadata
file in a merge request, "fdroid build" would be triggered. If they then
updated the merge request with a change to another file, then the next run
would not include a "fdroid build" job, since no metadata file was changed
in that push.
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.
Those shouldn't be needed in the current setup.
lint is already exempted in pipelines triggered via CI_JOB_TOKEN
pages: is the only triggered job currently (via an explicit
TRIGGER_TOKEN, checkupdates gets triggered via CI_JOB_TOKEN)
* run 250 app batches, let's see if our runner can handle the resulting
14 jobs in parallel
* stagger the startup of the jobs by 60 seconds
* use a specialized image so we save setup time per job
Batch checkupdate invocations into calls with 100 apps. This should
allow more than enough headroom for gitlab CI runner limits.
Currently it'll spawn 34 child pipelines, these each complete in about
15-20 min.
