[biglittlebigben]

livekit/gstreamer publishes rebuilds of a GStreamer release with a revision number
(1.28.7-1-dev, 1.28.7-2-dev). The .gst-version custom manager only accepted
X.Y.Z-dev tags and compared versions as semver, which reads -2 as a prerelease
ranked below 1.28.7, so Renovate never proposed a rebuild.

• matchStrings and extractVersionTemplate accept an optional -N revision.
• Regex versioning reads the revision as a build number, so
  1.28.7 < 1.28.7-1 < 1.28.7-2 < 1.28.8.

A local renovate --platform=local --dry-run=lookup now proposes 1.28.7 → 1.28.7-2
as a patch update.

🤖 Generated with Claude Code

[devin-ai-integration]

Devin Review found 1 potential issue.

[devin-ai-integration]

🟡 Scanner misses GStreamer revision updates

When matchStrings enables a revision update, the scanner base image stays pinned to 1.28.7-dev. Scanner builds then use the old GStreamer image instead of the revision used by ingress.

Learn more

The scanner has a hardcoded GStreamer base-image tag because its build receives no GSTVERSION argument. Renovate's custom manager updates only .gst-version. Once it accepts revisions, a revision-only PR can pass scanner builds without testing the GStreamer image selected for ingress. The hardcoded tag could already drift on a normal version bump; revision updates create another way to reach that mismatch.

Example: With .gst-version at 1.28.7, Renovate proposes 1.28.7-2. Ingress builds from 1.28.7-2-dev, but the scanner still builds from 1.28.7-dev.

Recommended fix: Update the scanner base image in the same Renovate PR, or make the scanner build consume .gst-version without a second hardcoded tag. Verify both base images use the same revision after a revision-only update.

---

Was this helpful? React with 👍 or 👎 to provide feedback.