- isobuilder6.iguana
- isotester7.iguana
- isotester8.iguana

refs sysadmin#17846

refs sysadmin#17846

We want that node connected to Jenkins but not actually being assigned
builds for now.

This reverts commit ec08aff0.

This reverts commit 4db52b22.

Closes sysadmin#17715

… so that Jenkins jobs pick up new branches and commits, until
"Configure GitLab remote mirrors in Gitolite (#50 (closed), #57)"
(from https://salsa.debian.org/tails-team/gitlab-migration/-/issues/43)
is completed.

The Git hook that's supposed to trigger jobs when we push tells Jenkins that
things have changed at gitolite3@, but before this commit, the Jenkins jobs
tracked gitolite@, so Jenkins is like "well, whatever, none of my jobs care
about the gitolite3@ remote, I'll go back to the beach".

Let's teach the Jenkins jobs that they're now tracking gitolite3@,
so they react as intended to Git pushes.

This reverts commit 6406d4a3.

Let's see if it's back on tracks.

refs: #10747

This reverts commit c80e99db.

This reverts commit 70cb887b.

Once the automatic build_Tails_ISO jobs generation will be running,
these jobs will be stored in the corresponding sub-directory, so we have
to move the actual one in there before to prepare the switch and not
ending with duplicated jobs configuration.

Confirmed it works.

Apparently, without that trigger, the "build on Git push" feature doesn't
work anymore. No need to trigger a daily build for this reason though.

Revert "Drop the daily pollscm trigger for all jobs that had one."

This reverts commit 2d3e1344.

We have Git post-update hooks for all of them. And for all ISO builds, we anyway
have a "timed: @daily" trigger that ensures we build them daily, even if Git
wasn't modified — e.g. because of APT changes that are not under our control.

That's not needed anymore: the built ISO filenames tell us what commit they were
built from, as does the Jenkins web interface.

That's annoying: the output of `git tag' is growing beyond control.

Still, keep the push_Tag builder around, since things might be different for
other, future kinds of builds.

Tails builds depend on the state of constantly changing APT repositories, so it
is useful to constantly verify that it still works.