Lewis John McGibbney created TIKA-4914:
------------------------------------------
Summary: Fix tika-helm daily Docker image version bump CI for Tika
4.x tags
Key: TIKA-4914
URL: https://issues.apache.org/jira/browse/TIKA-4914
Project: Tika
Issue Type: Bug
Components: tika-helm
Reporter: Lewis John McGibbney
Assignee: Lewis John McGibbney
Fix For: 4.1.0
The scheduled GitHub Action "Update Tika Docker Image Version" in
apache/tika-helm has been failing daily for a long time.
Example:
https://github.com/apache/tika-helm/actions/runs/35426111218/job/105852220512
The "Determine new tag" step only accepts legacy four-part Docker tags matching
^[0-9]+.[0-9]+.[0-9]+.[0-9]+-full$ (e.g. 3.3.1.0-full). Tika 4 images on DH are
published as 4.0.0-full and 4.0.0-1-full. The workflow also only inspects the
10 most recently updated DH tags, which are dominated by SNAPSHOT and latest
tags. grep finds no match and the job exits 1 under pipefail. This is a
straightforward bug and shortsight in the logic I put in place when I
iattempted to implement the automation logic in the first place.
The chart is still on appVersion 3.3.1.0-full / version 3.3.1.
The ticket will fix the workflow so it paginates Docker Hub, selects the latest
stable -full tag (both 3.x four-part and 4.x three-part / rebuild schemes),
ignores SNAPSHOT/alpha/beta/rc/latest, and derives Chart.yaml version as SemVer
MAJOR.MINOR.PATCH only.
Chart version mapping must stay Artifact Hub / Helm OCI compatible:
* 3.3.1.0-full -> 3.3.1
* 4.0.0-full -> 4.0.0
* 4.0.0-1-full -> 4.0.0 (do not use 4.0.0-1; that is a SemVer prerelease and
would sort below 4.0.0)
I will not bump the chart to Tika 4 in the same change; after the workflow fix,
the existing auto-update job can open a separate version bump PR. PR coming
up...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
