Update GitLab Elasticsearch Indexer to 5.14.14

🤖 AI-authored change.

master builds an indexer without the CVE-2026-88765 ICU fix, and the open renovate MR would make it worse. The pin was 5.14.12, which predates the fix. The renovate MR moves it to 5.14.13 — a tag cut from v5.14.7, not from main.

What does this MR do and why?

Bumps GITLAB_ELASTICSEARCH_INDEXER_VERSION from 5.14.12 to 5.14.14.

Tag	go directive	has the ICU fix	contains v5.14.12
v5.14.12 (current pin)	go 1.26.0	no	—
v5.14.13 (renovate's target)	go 1.25.0	yes	no
v5.14.14 (this MR)	go 1.26.0	yes	yes

• 5.14.13 is a regression on this branch. merge_base(main, v5.14.13) is cce30fded8, the v5.14.7 release commit, so v5.14.12 is not an ancestor of it. Bumping there drops 26 commits released in v5.14.8..v5.14.12, including the Go 1.26 update and pgx 5.10.0 (itself a CVE fix).
• v5.14.14 is the fast-forward. v5.14.12 is an ancestor of v5.14.14, and v5.14.14 carries the ported ICU fix, so this adds the fix and drops nothing.
• Go 1.26 is not a constraint here. The Go-1.25 requirement that made 5.14.13 right for the 18.11 and 19.0 lanes belongs to those omnibus builders; master is unaffected.

The stable-branch bumps to 5.14.13 are correct and stay as they are: !255493 (merged) (18.11) and !255494 (merged) (19.0).

References

• Renovate's master MR, superseded by this one: !255134 (closed)
• Lineage evidence: $6055357

Reviewer focus: whether master should instead wait for a v5.14.15 that lands the fix through the security repo's normal path, rather than taking v5.14.14 directly. Every claim above is a merge-base fact; that one is a release-process judgement.

How to set up and validate locally

git clone https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer && cd gitlab-elasticsearch-indexer
git merge-base --is-ancestor v5.14.12 v5.14.14 && echo "fast-forward"
git merge-base --is-ancestor v5.14.12 v5.14.13 || echo "would drop commits"

---

🤖 Automated change — mention me to get a response. Feedback welcome. Ask to speak to John directly anytime.

Mechanism, citations and verification (for agents / deep readers)

Mechanism

One-line change to GITLAB_ELASTICSEARCH_INDEXER_VERSION: 5.14.12 -> 5.14.14. Nothing else in the diff.

Verification

Re-derived in a fresh clone of gitlab-org/gitlab-elasticsearch-indexer at origin/main c7599399:

• merge-base(main, v5.14.13) = cce30fded840a8be1df68381c80d04e471f219fe, which git log -1 shows as Merge branch 'release_v5.14.7_...' — identical to git rev-parse v5.14.7^{commit}.
• git merge-base --is-ancestor v5.14.12 v5.14.14 exits 0; the same test against v5.14.13 exits 1. git rev-list --count v5.14.13..v5.14.12 = 26.
• The Go 1.26 commit 97c1f66e0b and the pgx bump 5fd5fa7ae2 are each reachable from v5.14.12 and v5.14.14, unreachable from v5.14.13.
• third_party/icu/go.mod exists at v5.14.13 and v5.14.14, absent at v5.14.12. git diff v5.14.13 v5.14.14 -- third_party/icu/c_bridge.c third_party/icu/convert.go is empty, so the two tags ship byte-identical fixed sources — the fix commit has different SHAs on each lineage (a74eefbf vs 268c48b) because it was ported, not cherry-picked.
• go directives read from git show <tag>:go.mod.

What I did not verify

• No build and no test run of the indexer at v5.14.14; the fix's runtime behaviour is unverified here.
• Whether an exception request covers CVE-2026-88765. A keyword search of the release tasks tracker found none, but a differently-titled one elsewhere would not have matched.
• Whether release management would prefer master take this tag versus a later one — that is the Reviewer focus question and is theirs to answer.
• That the omnibus builders for 18.11 and 19.0 ship Go 1.25; only the indexer's own go.mod directives were read.