fix(autodiscovery/dockercompose): skip images whose tag is not a version - #9760

No existing issue — happy to open one if you'd prefer the usual Fix #XXX reference.

NewDockerImageSpecFromImage returns nil when the tag cannot be recognized as a version (dockerimage/spec.go:103), so sourceSpec is nil for any :latest or variant-suffixed tag. Two bugs follow, both from inlining code that the dockerfile crawler keeps in a per-image function, where return nil, nil means "skip this image".

1. Nil dereference — compose.go:164

versionFilterPattern, err = d.versionFilter.GreaterThanPattern(imageTag)
tagFilter = ""
if err != nil {
	logrus.Debugf("building version filter pattern: %s", err)
	sourceSpec.VersionFilter.Pattern = "*"   // sourceSpec is nil here
}

The two functions choke on the same input, so they always fail together: a tag that getTagFilterFromValue doesn't recognize is also a tag sv.NewVersion refuses. Whenever this branch is entered, sourceSpec is nil.

The write is also dead even when it isn't nil — nothing reads sourceSpec.VersionFilter after the block at compose.go:144-154. What reaches the template is the local versionFilterPattern, which at that point holds the empty string returned by the failed call. dockerfile.go:167 assigns that local, which is both nil-safe and the value actually rendered — this PR does the same.

Reproducer, panics on v0.119.0 and on main:

# updatecli.d/dc.yaml
autodiscovery:
  crawlers:
    dockercompose:
      versionfilter:
        kind: semver
        pattern: patch

# docker-compose.yml
services:
  a:
    image: example.test/foo/bar:pg18-latest

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x90 pc=0x16eed1e]

goroutine 1 [running]:
...dockercompose.DockerCompose.discoverDockerComposeImageManifests(...)
        pkg/plugins/autodiscovery/dockercompose/compose.go:164

addr=0x90 is consistent with a nil base plus the field offset: unsafe.Offsetof puts Spec.VersionFilter.Pattern at 136 (0x88), and a string assignment stores two words, so the fault surfaces on the second one.

2. The whole crawl is abandoned — compose.go:190

In the template selection, sourceSpec == nil with digest: false reaches return nil, nil. Inside for _, svc := range svcList that discards the manifests accumulated so far and ends discovery for every remaining compose file, rather than skipping one service.

A single :latest service therefore makes the crawler emit no pipeline at all for the repository, exit 0, and say nothing above Info level. This is how I hit it: a compose file whose images were all pinned except one stopped being watched entirely, silently.

Reproducer — no versionfilter, so the panic above is not reached:

# docker-compose.yml — discovers 0 pipelines, expected 1
services:
  aaa-pinned:
    image: cr.agentgateway.dev/agentgateway:v1.4.1
  zzz-latest:
    image: example.test/foo/bar:latest

Test

cd pkg/plugins/autodiscovery/dockercompose
go test

Scenario 3 in main_test.go covers both: the fixture lists the unparseable-tagged service after the pinned one, so the assertion on a single expected pipeline fails if the accumulated manifest is dropped. It needs its own testdata-unparseable-tag/ directory because searchDockerComposeFiles walks recursively, and a fixture under testdata/ would change the expectations of scenarios 1 and 2.

Verified that the test fails without the fix — panic inside TestDiscoverManifests/Scenario_3, at compose.go:164 — and passes with it. gofmt -l and go vet are clean on the package.

Additional Information

Checklist

• I have updated the documentation via pull request in website repository — not applicable, no user-facing behaviour is documented differently.

Tradeoff

Keeping the versionFilterPattern = "*" fallback rather than deleting the branch is arguably belt-and-braces: in the common case the image is skipped a few lines later anyway, so the value is discarded. It still matters for degenerate tags such as 1. — ^\d*(\.\d*){1}$ matches it since \d* accepts the empty string, so the spec is non-nil, while sv.NewVersion("1.") fails — and it keeps the two crawlers symmetrical.

Potential improvement

matchingRule.go:39 declares ruleResults outside the for _, matchingRule := range m loop and never resets it, so a rule that follows a non-matching one can never match. Present in the dockercompose, dockerfile and other copies of that helper. Out of scope here; happy to send a separate PR if you want it fixed.

Co-authored with Claude Opus 5.