fix: run infrahubctl generator on target kinds without a name attribute - #1291
fix: run infrahubctl generator on target kinds without a name attribute#1291pthmas wants to merge 1 commit into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. @@ Coverage Diff @@
## stable #1291 +/- ##
==========================================
+ Coverage 84.24% 84.37% +0.13%
==========================================
Files 147 147
Lines 13066 13037 -29
Branches 1940 1928 -12
==========================================
- Hits 11007 11000 -7
+ Misses 1494 1477 -17
+ Partials 565 560 -5
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 2 files with indirect coverage changes 🚀 New features to boost your workflow:
|
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed across 3 files
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
ogenstad
left a comment
ogenstad
left a comment
There was a problem hiding this comment.
For a change like this we also need to ensure that we have the same behavior within Infrahub itself. I.e. when a generator runs within Infrahub. Does this already work as expected when the generator runs inside Infrahub or was this validated?
Deploying infrahub-sdk-python with
|
| Latest commit: |
3a69f22
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://c0e7c87b.infrahub-sdk-python.pages.dev |
| Branch Preview URL: | https://issue-1289.infrahub-sdk-python.pages.dev |
There was a problem hiding this comment.
All reported issues were addressed across 3 files (changes from recent commits).
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
|
@ogenstad the server never had this bug: it resolves each target’s variables with |
There was a problem hiding this comment.
All reported issues were addressed across 3 files (changes from recent commits).
Requires human review: Auto-approval blocked because this review re-detected 1 unresolved issue already reported by Cubic.
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
`infrahubctl generator` built the per-target params from a hardcoded `name` attribute and aborted with "The node doesn't have an attribute for name" whenever the target group held members of a kind without one. It also read the query variables from the first parameter key rather than from the declared attribute path. Resolve the whole parameters mapping with `extract()`, the same call Infrahub makes when it runs a generator, so target kinds without a name work, every declared parameter reaches the query, and a CLI run shares its tracking group with a server run. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2 participants
Why
infrahubctl generator <generator>exits immediately withError: The node doesn't have an attribute for namewhen the generator'stargetsgroup holds members of a kind that has nonameattribute. The generator never runs. The same generator works server-side in a proposed change, because the CLI is the only path that builds its per-target values this way. Reported by a customer whose target kind is a firewall rule identified byrule_id.Goal: the CLI runs the generator once per group member whatever attributes the target kind happens to have, deriving the per-target values the same way Infrahub does.
Closes #1289
What changed
Behavioral changes:
nameattribute no longer abort the run.Implementation notes: the per-target values now come from
member.peer.extract(params=generator_config.parameters)— the same call Infrahub makes atbackend/infrahub/generators/tasks.py:246. That resolves each parameter's declared path (rule_id: rule_id__value) rather than reading the parameter key as an attribute name, which only worked when the two coincided. Forparameters: {name: "name__value"}the result is identical to before, so existing tracking groups keep their names.What stayed the same: no CLI signature change, no schema change, server-side execution untouched.
How to review
infrahub_sdk/ctl/generator.py— the group loop now resolves the parameters mapping in one call, and the hand-rolled first-key lookup above it is gone. The resolved dict serves as both the query variables and the generator params, as it does server-side.How to test
Manual: define a kind with no
nameattribute, add nodes to aCoreStandardGroup, point a generator definition'stargetsat it with a parameter on one of that kind's own attributes, and runinfrahubctl generator <generator>with no variables. Before: exits withThe node doesn't have an attribute for name. After: one run per member.Impact & rollout
parameters: {name: "name__value"}, the resolved values are identical to before — same tracking group names.Checklist