in this release |
✨ new features |
- Bolt now merges output from stdout and stderr when running commands and scripts. When running Bolt with human-readable output, the output will now resemble what you would see when running the action directly on the target. Results from these actions, and JSON output, now include a new merged_output key in addition to the existing stdout and stderr keys.
- You can now convert YAML plans by name instead of by file path when using the bolt plan convert command and Convert-BoltPlan cmdlet. For more information about converting YAML plans to Puppet language plans, see the docs.
- The prompt plan function has a new default option which you can use to set a default value for the prompt. If the user does not provide input, or stdin is not a tty, the function will return the default value. Check out the plan function reference to see how to use this function.
- You can now prompt users to select an option from a menu of options with the prompt::menu plan function. To see how to use this function, check out the plan function reference.
- The lxd transport has a new remote configuration option, which can be used to configure Bolt to connect to a remote LXD server. For a full list of configuration options available to this transport, see the transport reference.
- Bolt now displays a welcome message to users running their first Bolt command if the command is bolt, bolt --help, or bolt help.
- Bolt now ships with the latest versions of the
puppetlabs-puppet_agent, puppetlabs-puppet_conf, and puppetlabs-reboot modules.
|
🔧 bug fixes |
- Bolt now properly validates that the env_vars option for the run_command and run_script commands is a hash, raising a helpful error message if it is not.
- Hash and array values set under the env_vars option are now converted to JSON. Previously, these values were stringified and had Ruby-style syntax.
- Bolt no longer errors when showing task information when the task has a parameter that does not define a type.
- Bolt no longer errors when showing task information for a task that can run in no-operation mode.
- Bolt now handles malformed _error values returned from tasks in the Orchestrator.
|
| VIEW THE RELEASE NOTES |
|
|
in the works |
- Performance improvements on Windows
- Shipping the PuppetBolt module to the PowerShell Gallery
- Improvements to running scripts
- A plan function to run containers
|
|
|
nuts and bolts |
Each month, we'll highlight a different Bolt feature and cover the details on what it is, why you might want to use it, and how it can be used in your workflows.
March's highlighted feature is: BoltSpec! | What is BoltSpec? BoltSpec is a library of helpers that ships with Bolt. It is intended to be used with RSpec, a testing tool, to write unit tests for your plans. Specifically, BoltSpec's helpers let you test the behavior of your plans without the need to connect to targets.
Why should I use BoltSpec?
Because plans can include complex logic that automates different jobs, it's important to test that the plan behaves as you expect. BoltSpec lets you easily write tests for your plans so you can test their behavior in development and catch any errors before your plans are used in production. Also, because BoltSpec stubs out Bolt functions that connect to targets, you don't need to worry about provisioning containers or VMs to run these tests.
How do I use BoltSpec? Using BoltSpec is as easy as installing and configuring rspec-puppet for your module or project, and then adding a couple lines to your tests' configuration file. If you already develop Puppet modules using the Puppet Development Kit (PDK), then most of this is already done for you. Going over all the details of using BoltSpec to test your plans is a little much for an email. So if you're interested in testing your plans, why not check out our new Testing Plans documentation? |
|
| VIEW THE DOCUMENTATION |
|
|
|
|
|
