- Create custom-cache-tag for pkglistgen to enable separate cache dir
name in case of parallel running
- Add custom-cache-tag to SLSA services
- Check for systemd service instead of process to ensure that SLSA
services will not run in parallel
- Change pkglisgen timer to avoid overlap with relpkggen timer
- Refactor log
- Unify log for pkglistgen
- Replace external while true loop with a systemd timer for pkglistgen
- Add process check on verify-build-and-generatelists and
generate-release-packages to avoid start pkglistgen when there is an
instance that is already running it
- SLSA services must not share the same workdir
The service is down for 2 years and more and it was unused ever since.
The idea just never took off (also because it was pretty late in the
cycle and leap wasn't developed much longer the way it used to when
the design for this was created).
For the next SLE/Leap it's just very, very unclear how it will look
like and I'm 99% sure it's not going to go back to old Leap. So the
whole operator needs more work and maintenance than the current team
has, so keep it in the git history only.
This plugin only works if run under an account owning the
target project (as I had it running with my own credentials
back in the day). As we no longer do that, the check_dups approach
is dead - and declining superseded requests from staging-bot
superseded (pun intended) this approach
There were still exceptions not caught - and I have the suspicion
that the memory leaks we see in production are caused by the reconnects
(if you google for python memory leaks you end up with pika and lxml
examples - both we use here, so a restart every couple of hours can't
hurt)
The value should allow ample time for seldom larger runs and such and is
purely a safe-guard from a service being stuck for weeks until noticed. If
any values turn out to be too small simply increase.
Now that repo_checker will skip identical builds this will increase the
chances that repo_checker project_only hits the project when it is not
building and will decrease the wait time for updates.
This allows for non-ephemeral queries to be cached indeinitely in the
future (like source queries that include the revision). For development
one may use --heavy-cache to be able to quickly iterate.