LS_RELEASE lookup swallows skopeo pull failures, so -lsN restarts at ls1 and an existing tag gets overwritten

Start with the LS_RELEASE lookup and retry_ghcr in ansible/roles/repository/templates/Jenkinsfile.j2, then trace how an empty result reaches LS_TAG_NUMBER and the push steps. Reproduce the failure path from the linked Jenkins logs and review the existing retry logic. Done means lookup failures cannot silently produce and push ls1 over an existing tag, while a genuinely new image can still start at ls1.

Is there an existing issue for this?

• I have searched the existing issues

This is the failure described in linuxserver/docker-wireguard#333 ("Every once in a while it fails and starts from 1"). I'm reporting it again because this time it also overwrote an existing version tag, and both affected builds still finished SUCCESS.

Current Behavior

The LS_RELEASE step in ansible/roles/repository/templates/Jenkinsfile.j2 (line 136 @ 4c0cbaf):

retry_ghcr docker run --rm quay.io/skopeo/stable:v1 inspect docker://ghcr.io/${LS_USER}/${CONTAINER_NAME}:{{ release_tag }} \
  | jq -r '.Labels.build_version' | awk '{print $3}' | grep '\\-ls' || :

1. retry_ghcr (L16–50, added in 583e5c0) only retries when stderr matches retry-after:|toomanyrequests|too many requests. A quay.io 502 while pulling the skopeo image fails right away.
2. || : hides the failure, so LS_RELEASE is empty.
3. LS_RELEASE_NUMBER is then empty too, and LS_TAG_NUMBER (L171–182) becomes $(( + 1)), which is 1.
4. The build tags, pushes and releases <version>-ls1 and ends with Finished: SUCCESS.

Seen on Docker-Pipeline-Builders/docker-sonarr/master:

• #893 (2026-10-20): the skopeo pull worked. It read 4.0.20.3014-ls329 and built 4.0.20.3014-ls330.
  https://ci.linuxserver.io/job/Docker-Pipeline-Builders/job/docker-sonarr/job/master/893/consoleText
• #894 (2026-10-20, a few minutes later):

  docker: unknown: failed to copy: httpReadSeeker: failed open: unexpected status from GET request to https://quay.io/v2/skopeo/stable/blobs/sha256:f7f612bb210ed468b26a040ac658f93fe06dd02bd9b1b324743949933127de0f: 502 Bad Gateway
  

  It then built META_TAG: '4.0.20.3014-ls1', pushed it, created GitHub release 4.0.20.3014-ls1, and ended with SUCCESS.
  https://ci.linuxserver.io/job/Docker-Pipeline-Builders/job/docker-sonarr/job/master/894/consoleText
• #896 (2026-10-24 01:45 UTC): another quay.io 502 (blobs/sha256:ec1cf86ab7be…). It produced META_TAG: '4.0.20.3014-ls1' again and pushed new images over the existing 4.0.20.3014-ls1 tag. Creating the GitHub release then failed with Validation Failed / already_exists, and the build still ended with SUCCESS.
  https://ci.linuxserver.io/job/Docker-Pipeline-Builders/job/docker-sonarr/job/master/896/consoleText

So 4.0.20.3014-ls1 now points at a different image than the one released on 2026-10-20, and no GitHub release exists for the new image.

Expected Behavior

If the previous -lsN can't be determined, the build should not continue and push. For example:

• Retry the skopeo pull/inspect on 5xx and network errors too, not only on 429. Since retry_ghcr was only just added, extending its match to 5xx errors (502 Bad Gateway, unexpected status) would cover this case.
• If LS_RELEASE is still empty after the retries while the release tag exists, fail the build instead of continuing with an empty number. A genuinely new image, where the tag doesn't exist yet, would still start at ls1.
• Optionally, refuse to push a META_TAG that already exists in the registry.

That keeps version tags immutable, in line with the reproducibility policy stated in other issues.

Steps To Reproduce

Not reproducible on demand. It happens whenever quay.io/skopeo/stable:v1 can't be pulled on a builder that doesn't have it cached. The console logs above show both cases.

Environment / Docker creation / Container logs

Not applicable: this is a CI/tagging problem, not a runtime problem. The relevant logs are the Jenkins console logs linked above.