COMP: Bump srvaroa/labeler v0.8 → v1 to avoid per-run Go build flakes

[hjmjohnson]

The Label PRs workflow has been intermittently failing across recent PRs (#5775, #6177, #6164 …) with Docker build failed with exit code 1 from go: gopkg.in/check.v1: net/http: TLS handshake timeout. Pinning at srvaroa/labeler@v0.8 builds the Go binary from source on every run; bumping to @v1 (currently v1.14.0) uses the pre-built image introduced in v1.8.1 and skips the Go-compile step entirely.

Diagnosis

srvaroa/labeler@v0.8 (2018-2019) ships a Dockerfile that runs go build -o action ./cmd inside the CI runner. The build pulls dependencies from gopkg.in (notably gopkg.in/check.v1 and gopkg.in/yaml.v2); gopkg.in intermittently TLS-handshake-times-out from GitHub-hosted runners, which kills the labeler container build before the action can run. Affected jobs report no real error — just network flake fetching Go modules.

srvaroa/labeler v1.8.1 introduced a pre-built Docker image, so newer versions never compile Go in the runner and never touch gopkg.in. The floating v1 tag tracks the latest patch (currently v1.14.0).

Compatibility check

The current .github/labeler.yml only uses the v0.8-era config schema -- per-rule title: regexes ("^COMP:.*" etc.) and files: glob lists. Per the upstream README those are still supported in v1.x (the only deprecated key in 1.x is size-above/size-below, which we do not use). No config changes required.

Pinning choice

Used @v1 (floating major) rather than @v1.14.0 (exact pin). Tradeoff:

	@v1	@v1.14.0
Auto-picks up future patch fixes	yes	no
Maintenance burden	none	manual bumps
Risk of surprise minor breakage	minimal — labeler is read-only and the workflow doesn't gate merges	none

Happy to switch to the exact tag if reviewers prefer; one-character diff.

Test plan

• pre-commit run --all-files clean
• Verify the Label PRs workflow on this very PR runs green (will confirm the fix works end-to-end)

[hjmjohnson]

Heads-up: the failing Label PRs / build check on this very PR is the same flake the PR fixes -- and it's expected to stay red here.

pull_request_target runs the workflow file from the target branch (main), not the PR branch, so this PR's run uses the old srvaroa/labeler@v0.8 from main and rebuilds the Go binary, hitting the same gopkg.in TLS-handshake timeout. The @v1 bump in this PR only takes effect on future PRs once this lands on main.

In other words: this PR is the chicken-and-egg fix; the red check is proof that the bug exists, and merging the bump unblocks every subsequent PR. Other CI lanes (build, pre-commit, ARMBUILD, Azure) are still pending and should pass since they don't depend on the labeler at all.

[hjmjohnson]

Force-pushed a5d4ac87ee → 577ce95e41 to also migrate .github/labeler.yml to v1's schema. The bare action-version bump alone would silently break labeling: v1 changed the YAML shape from a flat dict-of-rules to a versioned labels: list of {label, title, files, ...} objects.

Pattern semantics are unchanged (both v0.8 and v1 use Go RE2 regex matched unanchored against PR file paths), so the 25 label rules are migrated 1-to-1 with their existing patterns intact. No new labels added, no labels removed.

Validation

• python3 -c 'import yaml; yaml.safe_load(open(".github/labeler.yml"))' parses cleanly.
• 25 rules counted (8 type: title-prefix + 14 area: file-glob + 3 type: file-glob); matches the previous file's rule set.
• pre-commit run --all-files clean.

[greptile-apps]

Greptile Summary

This PR bumps srvaroa/labeler from @v0.8 to @v1 in the Label PRs workflow to eliminate intermittent Go build failures caused by gopkg.in TLS timeouts. The labeler.yml config is simultaneously migrated from the v0.8 flat-key schema to the v1 version: 1 / labels: list schema, with all existing label rules preserved.

Confidence Score: 4/5

Safe to merge; one P2 supply-chain note about the floating @v1 tag that the author already acknowledges.

The change is minimal and well-reasoned. The only concern is using a floating major-version tag (@v1) rather than a pinned commit SHA for an action running under pull_request_target. The PR description explicitly discusses this trade-off and permissions are scoped to pull-requests: write, so blast radius is limited. No logic errors or schema regressions were found.

label-pr.yml — floating @v1 tag under pull_request_target; consider pinning to a commit SHA for supply-chain hardening.

Important Files Changed

Filename	Overview
.github/workflows/label-pr.yml	Single-line change bumping srvaroa/labeler from @v0.8 to @v1 (floating tag); workflow uses pull_request_target which warrants pinning to a commit SHA rather than a mutable tag.
.github/labeler.yml	Migrated config from v0.8 flat-key schema to v1 version: 1 / labels: list schema; all label rules and file/title patterns are preserved correctly.

Sequence Diagram

sequenceDiagram
    participant GH as GitHub
    participant WF as label-pr.yml (pull_request_target)
    participant LA as srvaroa/labeler@v1 (pre-built image)
    participant Repo as Repository Labels

    GH->>WF: pull_request_target event
    WF->>LA: run action (GITHUB_TOKEN)
    LA->>LA: read .github/labeler.yml (v1 schema)
    LA->>LA: match PR title + changed files → labels
    LA->>Repo: apply labels via API (pull-requests: write)
    Note over LA: No Go compile step,<br/>no gopkg.in network calls

Loading

_{Reviews (1): Last reviewed commit: "COMP: Bump srvaroa/labeler v0.8 → v1 to ..." | Re-trigger Greptile}

[greptile-apps]

Floating tag with pull_request_target is a supply chain risk

The workflow is triggered by pull_request_target, which runs with write access to the base repository and has access to GITHUB_TOKEN. A floating @v1 tag means any new commit pushed under that tag by the upstream maintainer is automatically trusted and executed with those privileges. Pinning to a specific commit SHA (e.g., srvaroa/labeler@<sha>) eliminates silent tag-overwrite risk. The PR description already notes this trade-off, and the permissions scope is limited to pull-requests: write, which meaningfully reduces blast radius — but pinning the SHA is the common defense-in-depth recommendation for pull_request_target workflows.

[hjmjohnson]

I think the v1 tag is what we want to minimize future maintenance burden.

[hjmjohnson]

@blowekamp @dzenanz @thewtex I don't think that the floating tag is a sufficient enough concern to justify the added burden. NOTE: All PR's (including this one) will fail (or be really flakey) the Labeler CI until this (or similar) is merged into the main branch.