Latest release of jenkins-job-builder is now attempting to delete old
Jenkins views when updating but this new code triggers an exception when
deploying jobs on our Jenkins instance, so add option --jobs-only to
jenkins-job update command as a workaround to restore previous behavior.

When rebuilding a merge request for the swh-jenkins-dockerfiles repository
by manually triggering the job from the jenkins UI, the built images were
pushed on the swh container registry but it should only happen when pushing
a commit to the master branch.

Errors can happen otherwise when executed on a different node.

This was missed when the job was turned to a pipeline one.

This makes the image push fail, for obvious reasons...

The tag+push action was missing from builds triggered from the timer and
from a manual user action. We're now doing that as well.

To avoid polluting #swh-devel IRC channel with failed build notifications
when pushing merge requests to the swh-environment repository, separate the
builds triggered by gitlab with those triggered by a timer.

The gitlab triggered builds are now associated to the DENV/docker-tests
job while timed builds are still associated to the swh-docker-dev job.

Docker usage on Jenkins increased recently so run the cleanup job
more regularly to avoid errors related to disk being full while
running CI jobs.

Related to swh/infra/sysadm-environment#4846.

Add a trigger for swh-docker-dev job when pushing to swh-environment
repository, either commit or merge request, to build swh/stack docker
image and run the docker test suites.

The docker tests will be executed only if the content of the docker
directory changed but also when job is started by a timer or manually
by a user.

This needs to match a user/group with access to the docker socket
on the host system.

This should allow us to move to some more distributed jenkins testing, eventually

For some reason, likely due to the fact that it is a hidden one, that parameter
was not correctly transmitted to the job setting gitlab webhooks and the jenkins
jobs could not be triggered anymore.

Nevertheless, the webhooks job also has the same hidden parameter with the rotated
token as default value so we can safely remove the jenkins_token parameter for the
jenkins-jobs-builder job.

Pass it as a hidden parameter instead as jenkins now requires to manually
validate each groovy script for security concerns.

As a script is identified by the hash of its content, proceeding like
this avoid to revalidate the webhooks setting script each time the token
is rotated.

When testing jobs on a local Jenkins server, disable the cron triggers
and prefer to run jobs manually.

Related to !176.

Previously, merge requests were also rebuilt when pushing to the target
branch which is not required.

Since recently, merge requests are not rebuilt by Jenkins when pushing
new commits to it. This could be related to some default configuration
changes in latest release of GitLab plugin for Jenkins.

As that behavior is not enabled by default in gitlab trigger settings
explicitly enable it in jenkins jobs configuration.

More efficient in regards to our current way of building some specific images which are
growing forever (up until we got no more disk space on thyssen).
That's a simpler workaround than what's discussed in issue [1] [2]. We keep the last "2"
days images so the next build still benefits from it but we drop the rest (so no more
too much disk cost). As this job is triggered daily, that should keep those images in
check.

Provided, the following script is installed on the node:

```
$ root@thyssen:~# cat /usr/local/bin/clean-docker-images.sh

set -x

today=$(date --date '13:00' +%Y%m%d)
yesterday=$(date --date 'yesterday 13:00' +%Y%m%d)

images_to_drop=$(docker image ls \
    | grep -E "softwareheritage/(base|web|replayer)" \
    | grep -v $today \
    | grep -v $yesterday \
    | grep -v "latest")

if [ ! -z "$images_to_drop" ]; then
    echo $images_to_drop \
    | awk '{print $1":"$2}' \
    | xargs docker rmi
fi

docker system prune --filter 'label!=keep' --volumes --force
```

Refs. swh/infra/sysadm-environment#4846

[1] swh/infra/sysadm-environment#4848

[2] swh/infra/sysadm-environment#4846

It enables a better selection of the git branch to checkout when
dealing with gilab merge requests.

It enables to test proper build of docker images when their dockerfiles
are modified without impacting the images used by our Jenkins jobs.

In order to have a code coverage report focused on the changes of a merge
request displayed in the Jenkins UI, prefer to execute the {name}/master
job instead of the {name}/gitlab-builds one.

Indeed the {name}/gitlab-builds is triggered by pushing branches, tags
or merge requests which can confuse the git-forensics Jenkins plugin.
It is used to compute relative results that show what will be changed
if the  branch of the current build will be merged with the master branch.

By ensuring only {name}/master is executed when pushing to the master
branch, finding the reference commit a merge request is based on and its
associated build job is guaranteed.

The old job would trigger the jobs update on a merge request with source
branch "master", e.g. from a fork.

SWH migration to GitLab is now effective so we can remove jobs previously
triggered by Phabricator and simplify jobs configuration and pipelines code.

We need to checkout the branch merge-requests/${env.gitlabMergeRequestIid}
in that case.

Switch from GitLab staging to GitLab production URLs now all jobs
have been ported and tested to use GitLab instead of Phabricator.

This code snippet is used in numerous Jenkins pipelines so better
deduplicating it.

Add a job that will be executed when pushing tags to the maven-indexer-exporter
repository hosted on SWH GitLab.

Also rename configuration file to something more meaningful and update pipeline
script to match the style of the other ones in that repository.

Debian dependencies packages will be built when pushing gbp buildpackage tags
on the associated gitlab repositories.

Mirror tests will be executed when pushing changes to the swh-mirror
GitLab repository or when submitting merge requests.

This job rebuild the docker images used by Jenkins to run jobs.
It will be triggered on push events for the swh-jenkins-dockerfiles
repository hosted on SWH GitLab.

SWH migration to GitLab is incoming and we are not using elastic workers
yet in production so we still need to build debian packages for swh modules.

So add support for building the debian packages when pushing tags to swh
module repositories hosted on GitLab.

Documentation will be fully built when pushing changes to the swh-docs
GitLab repository or when submitting merge requests.

This job will be executed when pushing tags to a swh GitLab repository
in order to generate and upload Python wheels of swh packages.

Please note that the debian packaging part has not been ported yet.

Also, wheels upload are currently disabled until we fully migrate to
GitLab.

This job is responsible to setup the webhooks on swh GitLab repositories
enabling to trigger Jenkins builds when pushing changes or creating merge
requests.

It parses Jenkins jobs builder YAML configuration to get the name of the
repos with CI setup and set webhook URLs in GitLab projects through HTTP
requests to the GitLab REST API.

It is triggered at the end of the swh-jenkins-jobs-builder job after jobs
have been reconfigured.