Skip to content

compare-exiftool-full justfile recipe ignores pinned EXIFTOOL_VERSION, silently drifts cache #108

Description

@swackhamer

Found via

Independent exiftool-parity audit — while refreshing the harness cache to match the CI-pinned ExifTool version.

Bug

The persistent harness cache at /tmp/oxidex-exiftool-cache was stale at ExifTool 13.59 while both the local exiftool -ver and the CI pin (EXIFTOOL_VERSION: '13.55' in .github/workflows/jpeg-tag-matrix.yml) are 13.55. After manually refreshing the cache to 13.55 and running just compare-exiftool-full, running scripts/find_tag_gaps.py (which itself invokes just compare-exiftool-full internally) silently re-fetched "latest" from exiftool.org/GitHub API and re-pinned the cache back to 13.59, overwriting the fix mid-session.

Impact

The compare-exiftool-full justfile recipe (~line 713) doesn't respect EXIFTOOL_VERSION/any local pin — it always fetches whatever is "latest". This means:

  • Local parity runs can silently compare against a different ExifTool version than CI uses
  • Repeated runs (e.g. gap-report after a full-comparison) can flip the cached version out from under you without warning

In this instance tag counts were identical between 13.55 and 13.59 for the formats checked, so it didn't invalidate the audit, but it's a real correctness gap in the tooling that could cause phantom gaps/regressions in future runs.

Fix direction

Thread EXIFTOOL_VERSION (or an equivalent pin) through compare-exiftool-full and any recipe/script that transitively calls it, and skip re-fetching when the cached version already matches the pin.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions