fix: use latest Tekton releases and fix ConfigMap timing issue

[divyansh42]

Changes

Update E2E test setup to use latest stable releases for both Tekton Triggers and Pipelines, and fix the ConfigMap timing issue:

Pipelines:

• Remove v1.12.0 pin that was waiting for fix in fix: avoid spurious termination parse warning pipeline#10160
• Use latest release: https://infra.tekton.dev/tekton-releases/pipeline/latest/release.yaml
• Remove TODO comment about switching back to latest

Triggers:

• Skip nightly builds (currently broken) and use latest release directly
• Use latest release: https://infra.tekton.dev/tekton-releases/triggers/latest/release.yaml
• Fix timing issue: Wait for pods AFTER applying interceptors.yaml (not before)

Root Cause

Triggers v0.37.1 added a new ConfigMap config-triggers-core-interceptors for the GitHub Enterprise host allowlist feature (#2125). The triggers controller fatally crashes on startup if this ConfigMap doesn't exist, even though the feature defaults to disabled:

{"severity":"fatal","timestamp":"2026-09-24T06:49:19.266Z","logger":"controller",
"caller":"sharedmain/main.go:311","message":"Failed to start configmap watcher",
"error":"configmap \"config-triggers-core-interceptors\" not found"}

The ConfigMap is included in interceptors.yaml (verified in downloaded v0.37.1 release), but our installation order was broken:

Old broken order:

1. Apply release.yaml → Creates triggers-controller Deployment
2. Wait for pods → Controller starts, needs ConfigMap, crashes immediately
3. Wait for CRD to be Established
4. Apply interceptors.yaml → Creates ConfigMap (too late, pods already crashed)

Fix

Move wait_until_pods_running to AFTER applying interceptors.yaml. This matches the installation pattern used by tektoncd/triggers itself:

New correct order:

1. Apply release.yaml → Install CRDs and create Deployment
2. Wait for ClusterInterceptor CRD to be Established → Provides delay for image pull
3. Apply interceptors.yaml → Create ConfigMap before controller starts
4. Wait for pods → Controller now finds ConfigMap and starts successfully

The kubectl wait for CRD Establishment provides enough delay for the controller pod to be created and the container image to be pulled, but not yet started. By the time the controller binary runs and tries to read the ConfigMap, step 3 has already created it.

Submitter Checklist

• Includes tests (if functionality changed/added) — N/A, test infrastructure change only
• Run the code checkers with make check
• Regenerate the manpages, docs and go formatting with make generated — N/A, no code changes
• Commit messages follow commit message best practices

Release Notes

NONE

[divyansh42]

/hold

[divyansh42]

/hold cancel

[vdemeester]

/lgtm

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vdemeester

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [vdemeester]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment