Backport of 'Bump GitLab Elasticsearch Indexer to 5.14.14' to 19.4
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
- severity label and bug subtype labels (if applicable)
- If this MR fixes a bug that affects customers, the customer label has been applied.
- This MR has been approved by a maintainer (only one approval is required).
- Ensure the
e2e:test-on-omnibus-eejob 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.
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-eeat9225cb49.git diff --statagainst that base:1 file changed, 1 insertion(+), 1 deletion(-), naming onlyGITLAB_ELASTICSEARCH_INDEXER_VERSION. third_party/icu/c_bridge.csha256 in the indexer repo:313ad909...851f73c4at bothv5.14.13andv5.14.14;63f7f67e...c3009a36atv5.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 pgx5.10.0CVE bump that5.14.12already 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.