enforcedConfigLevel: resource is redundant and contradicts documented design
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 6
- Forks
- 19
- Avg merge
- 12h 36m
- Merged PRs (30d)
- 27
Description
Description
The enforcedConfigLevel field accepts three values: global, namespace, and resource. The resource level is redundant — it doesn't enable any useful behavior that namespace doesn't already cover, and it contradicts the project's own documented design principles.
What resource does
The getResourceFieldData function in pkg/config/config.go:397 switches on the enforced level. The resource case (line 402) reads selectors from globalSpec.Namespaces — the namespaces: block embedded in the global ConfigMap (tekton-pruner-default-spec).
The namespace case (line 453) reads selectors from namespaceConfigMap — the per-namespace ConfigMaps (tekton-pruner-namespace-spec).
Why this is a problem
- Contradicts documented design. The code comment at config.go:380 says: "Selector support ONLY for namespace-level ConfigMaps, NOT global ConfigMaps." But enforcedConfigLevel: resource is the exact code path that reads selectors from the global ConfigMap.
- Annotation override is a no-op. The only code that branches on EnforcedConfigLevelResource is history_limiter.go:227. It checks if the resource has a history limit annotation, but:
- If the annotation matches the config value — uses the annotation (same number, no difference)
- If the annotation doesn't match — falls back to the config value anyway
The annotation never actually overrides anything. The TTL handler (ttl_handler.go) has zero references to EnforcedConfigLevelResource. - namespace is a strict superset. The namespace fallback chain checks: (1) selector match from per-namespace ConfigMaps, (2) namespace root-level from per-namespace ConfigMaps, (3) namespace root-level from global ConfigMap's namespaces: block, (4) global root-level defaults. The resource chain only checks (1) from the wrong source, (3), and (4). So namespace covers more and reads from the correct data
source. - Never the effective default. config_defaults.go:25-27 sets the default to global via SetDefaults(). The fallback to resource at config.go:659 only triggers if SetDefaults() is never called, which doesn't happen in normal operation.
Proposal
- Remove enforcedConfigLevel: resource as a valid option
- Update the validation at config.go:918-924 to reject resource (or accept it as an alias for namespace during a deprecation period)
- Remove the dead annotation-check code at history_limiter.go:227-257
- Remove EnforcedConfigLevelResource constant from config.go:63-64
- Update any documentation that references three config levels
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the enforced-level handling in pkg/config/config.go, including getResourceFieldData, the validation, constants, and fallback logic. Then inspect history_limiter.go, ttl_handler.go, config_defaults.go, and documentation references; done means resource is removed or deprecated as specified, dead annotation logic is gone, and the documented configuration levels match validation and behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- backend, devops
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 65/100