Shipt has 1,100+ microservices with a 1:1 mapping of projects to repositories. Managing timeouts at the project level is not feasible at this scale. Harness enforces a "Most Restrictive Precedence" for timeouts. The Account-level default (e.g., 20m) acts as a hard global maximum that ignores higher values set at the project or pipeline level, even when "Allow Overrides" is checked. The Requirement:

Ability to "pick and choose" which build types can exceed global account limits.

Standard Builds (e.g., Golang): Should stay capped at 20m (Account Default) to prevent system abuse/memory leaks.

Heavy Builds (e.g., ML/Data Science): Justifiably need 60–70 minutes.

The Gap:

Harness currently enforces "Most Restrictive Precedence." Even if a Project or Template is set to 70m, the 20m Account default kills the process. Shipt cannot manage 1,100 projects individually, so they need this control at the Template level.Proposed Solution:

Change precedence logic from "Most Restrictive" to "Specific Overrides."

If "Allow Overrides" is enabled at the Account level, a value explicitly defined in a Template or Pipeline should become the new authoritative limit for that execution.

This allows Shipt to maintain a "Secure/Low" default for the masses while granting "High" limits only to vetted ML/DS templates.