useAnnotations: true bridge mode ignores allow-tags filter and uses incorrect tag sorting with newest-build strategy

[shvartz311]

Description

When using v1.1.1 CRD-based configuration with useAnnotations: true bridge mode (to maintain backward compatibility with annotation-configured Applications), the newest-build update strategy exhibits two critical bugs:

1. allow-tags regex filter is ignored during tag selection
2. Tag sorting selects wrong "newest" image when multi-arch and single-arch images coexist in the same repository
   Both bugs cause production image downgrades/wrong deployments.

Environment

• argocd-image-updater: v1.1.1 (chart 1.1.5)
• Registry: AWS ECR
• Strategy: newest-build via annotations
• Configuration: useAnnotations: true in ImageUpdater CR

Bug 1: allow-tags filter ignored

Application annotations:

argocd-image-updater.argoproj.io/silverbolt-bin-packed.allow-tags: "regexp:^ga-.*"
argocd-image-updater.argoproj.io/silverbolt-bin-packed.update-strategy: "newest-build"

ImageUpdater CR:

spec:
  applicationRefs:
    - namePattern: "*"
      useAnnotations: true

Expected: Only tags matching ^ga-.* should be considered. The updater should select ga-015fcaa as the newest matching tag.
Actual: The updater selected beta-015fcaa instead (same image digest, different tag name). This happened across 14 production tenant applications simultaneously. The beta-* tag does not match the allow-tags regex pattern.
It appears the tag filter is applied after selection rather than before, or not applied at all when reading from annotations in bridge mode.

Bug 2: newest-build picks wrong image across format boundaries

Application annotations:

argocd-image-updater.argoproj.io/configuration-manager.allow-tags: "regexp:^master-.*"
argocd-image-updater.argoproj.io/configuration-manager.update-strategy: "newest-build"

Registry state:

Tag	Pushed	Size	Format
master-2e869c0	2026-04-06	673 MB	single-arch
master-55c4b56	2025-09-07	851 MB	multi-arch OCI index

Expected: master-2e869c0 should be selected as it was pushed most recently.
Actual: master-55c4b56 (September 2025) was selected, causing a 7-month downgrade in production. The old image uses application/vnd.oci.image.index.v1+json (multi-arch manifest) while newer images are single-arch.
The v0.x newest-build strategy used the registry's push timestamp (imagePushedAt in ECR) for sorting. v1.1 appears to use the image manifest's internal created timestamp, which is misleading for multi-arch images.

Impact

These bugs caused production incidents:

• 14 tenant applications deployed with wrong tag prefix (beta- instead of ga-)
• 2 services downgraded to 7-month-old images
• 1 service changed to a latest tag
  All required manual intervention to revert.

Suggested fix

1. In the useAnnotations code path, ensure allowTags regex is applied to filter the tag list before GetNewestVersionFromTags sorts and selects.
2. For newest-build strategy, use the registry-reported push/upload timestamp rather than the image manifest's created field, matching v0.x behavior.

Workaround

Rolled back to v0.12 (annotation-based) which correctly applies allow-tags and sorts by registry push timestamp.