(PUP-10476) Use updated PAL api for catalog compilation #1798
Conversation
`bolt plan show <plan>` was failing when passed a project-level
plan due to the fact that the project path is a Pathname rather than a
string, unlike most modules. We now convert the path to a string in
`get_plan_info` so that any code interacting with the plan data can
treat it as if it came from any other module.
!bug
* **Fix `bolt plan show <plan>` for project-level plans**
([puppetlabs#1799](puppetlabs#1798))
This command was throwing errors due to a type mismatch that is now
resolved.
|
This makes sense to me. |
|
CLA signed by all contributors. |
joshcooper
changed the title
This commit updates the catalog compiler to use updates to PAL api to enable node definitions in plans and deserialized bolt types in apply blocks without relying on using public methods. This includes a refactor to clean up the compile_catalog method and make it more readable. !no-release-note
|
Depends on puppetlabs/puppet-runtime#343 |
|
Puppet runtime is now shipping puppet 6.16.0 |
lib/bolt/catalog.rb
Outdated
| node_name_value: target['name'], | ||
| # CODEREVIEW: Isnt this already the default? | ||
| # https://github.com/puppetlabs/puppet/blob/master/lib/puppet/parser/catalog_compiler.rb#L18 | ||
| rich_data: true, |
There was a problem hiding this comment.
Yes, and Puppet's default for this is true as well, and we shouldn't be picking up Puppet config anywhere. I think it's safe to remove.
This commit removes the `rich_data` setting from being overriden. This already has the default value we want https://github.com/puppetlabs/puppet/blob/master/lib/puppet/parser/catalog_compiler.rb#L18
| bolt_project: bolt_project | ||
| } | ||
|
|
||
| # Facts will be set by the catalog compiler, so we need to ensure |
There was a problem hiding this comment.
I think this actually belongs above the definition of shadow_vars, since this describes exactly what that function is doing.
There was a problem hiding this comment.
Or to above plan_vars =, whichever you think makes more sense.
There was a problem hiding this comment.
Or removed altogether, the current comment above the function definition does a pretty good job of getting the important point across
There was a problem hiding this comment.
Maybe just the target = request['target'] makes that a bit awkward. We need that target var there to access facts. The description i think is meant to descrive how and why topscope_vars is computed.
There was a problem hiding this comment.
I just thought it might be more clear placed elsewhere, but I don't think it's worth holding this up for.
4 participants
This commit updates the catalog compiler to use updates to PAL api to enable node definitions in plans and deserialized bolt types in apply blocks without relying on using public methods. This includes a refactor to clean up the compile_catalog method and make it more readable.