Backport of 'Bump GitLab Elasticsearch Indexer to 5.14.14' to 19.4

🤖 AI-authored change.

What does this MR do and why?

Backport of merge request 255533 to 19-4-stable-ee: indexer 5.14.12 -> 5.14.14, for the ICU charset-conversion buffer fix. 19.4 is the last active stable branch missing it.

5.14.14, not the 5.14.13 19.3/19.2 took: merge-base(v5.14.12, v5.14.14) is v5.14.12, so it fast-forwards; merge-base(v5.14.12, v5.14.13) is v5.14.7, so 5.14.13 would drop 26 commits 19.4 already has.

Reviewer focus: the tag choice — see the merge-base evidence below.

MR acceptance checklist

  • This MR is backporting a bug fix, documentation update, or spec fix, previously merged in the default branch.
  • The MR that fixed the bug on the default branch has been deployed to GitLab.com (not applicable for documentation or spec changes).
  • The MR title is descriptive (e.g. "Backport of 'title of default branch MR'"). This is important, since the title will be copied to the patch blog post.
  • Required labels have been applied to this merge request
  • This MR has been approved by a maintainer (only one approval is required).
  • Ensure the e2e:test-on-omnibus-ee job has succeeded, or if it has failed, investigate the failures.

Note to the merge request author and maintainer

See the patch release runbook for the process, and #releases for questions.


🤖 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 in GITLAB_ELASTICSEARCH_INDEXER_VERSION. Omnibus and the GDK read that file to choose the gitlab-elasticsearch-indexer tag they build, so the bump is the whole delivery path; nothing else in this repo reads the version.

Verification

  • Branch cut from origin/19-4-stable-ee at 9225cb49. git diff --stat against that base: 1 file changed, 1 insertion(+), 1 deletion(-), naming only GITLAB_ELASTICSEARCH_INDEXER_VERSION.
  • third_party/icu/c_bridge.c sha256 in the indexer repo: 313ad909...851f73c4 at both v5.14.13 and v5.14.14; 63f7f67e...c3009a36 at v5.14.12. The fix is in both candidate tags and absent from what 19.4 ships.
  • git merge-base v5.14.12 v5.14.14 -> 4e3c0ccf (= v5.14.12). git merge-base v5.14.12 v5.14.13 -> cce30fde (= v5.14.7), with 26 commits in between, including a Go toolchain update and a pgx 5.10.0 CVE bump that 5.14.12 already carries.
  • Patch release tracking: https://gitlab.com/gitlab-org/gitlab/-/issues/628646

What I did not verify

  • Whether merge request 255533 has reached GitLab.com production; it merged hours ago, so the "deployed to GitLab.com" box stays unchecked.
  • I did not build the indexer at 5.14.14, run its own suite, or exercise an Elasticsearch indexing run against a 19.4 GDK. The tag claims rest on the hashes and merge-bases above.

Merge request reports

Loading
Loading