bolt 3.13.0 → 3.14.1

data/lib/bolt_spec/plans/mock_executor.rb

@@ -39,6 +39,7 @@ module BoltSpec
         # plans that are allowed to be executed by the @executor_real
         @allowed_exec_plans = {}
         @id = 0
+        @plan_futures = []
       end
 
       def module_file_id(file)
@@ -280,7 +281,7 @@ module BoltSpec
         false
       end
 
-      def create_future(scope: nil, name: nil)
+      def create_future(plan_id:, scope: nil, name: nil)
         newscope = nil
         if scope
           # Create the new scope
@@ -295,13 +296,18 @@ module BoltSpec
         # Execute "futures" serially when running in BoltSpec
         result = yield newscope
         @id += 1
-        future = Bolt::PlanFuture.new(nil, @id, name: name)
+        future = Bolt::PlanFuture.new(nil, @id, name: name, plan_id: plan_id)
         future.value = result
+        @plan_futures << future
         future
       end
 
-      def wait(results, **_kwargs)
-        results
+      def get_futures_for_plan(plan_id:)
+        @plan_futures.select { |future| future.plan_id == plan_id }
+      end
+
+      def wait(futures, **_kwargs)
+        futures.map(&:value)
       end
 
       # Since Futures are executed immediately once created, this will always
@@ -310,8 +316,12 @@ module BoltSpec
         true
       end
 
-      def plan_futures
-        []
+      def get_current_future(fiber)
+        @plan_futures.select { |f| f.fiber == fiber }&.first
+      end
+
+      def get_current_plan_id(fiber)
+        get_current_future(fiber)&.current_plan
       end
 
       # Public methods on Bolt::Executor that need to be mocked so there aren't

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: bolt
 version: !ruby/object:Gem::Version
-  version: 3.13.0
+  version: 3.14.1
 platform: ruby
 authors:
 - Puppet
 autorequire: 
 bindir: exe
 cert_chain: []
-date: 2021-07-12 00:00:00.000000000 Z
+date: 2021-07-26 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: addressable
@@ -70,16 +70,22 @@ dependencies:
   name: ffi
   requirement: !ruby/object:Gem::Requirement
     requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: 1.9.25
     - - "<"
       - !ruby/object:Gem::Version
-        version: 1.14.0
+        version: 2.0.0
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: 1.9.25
     - - "<"
       - !ruby/object:Gem::Version
-        version: 1.14.0
+        version: 2.0.0
 - !ruby/object:Gem::Dependency
   name: hiera-eyaml
   requirement: !ruby/object:Gem::Requirement
@@ -460,16 +466,6 @@ files:
 - bolt-modules/prompt/lib/puppet/functions/prompt/menu.rb
 - bolt-modules/system/lib/puppet/functions/system/env.rb
 - exe/bolt
-- guides/debugging.txt
-- guides/guide.txt
-- guides/inventory.txt
-- guides/links.txt
-- guides/logging.txt
-- guides/module.txt
-- guides/modulepath.txt
-- guides/project.txt
-- guides/targets.txt
-- guides/transports.txt
 - lib/bolt.rb
 - lib/bolt/analytics.rb
 - lib/bolt/applicator.rb
@@ -538,6 +534,7 @@ files:
 - lib/bolt/pal/yaml_plan/step/script.rb
 - lib/bolt/pal/yaml_plan/step/task.rb
 - lib/bolt/pal/yaml_plan/step/upload.rb
+- lib/bolt/pal/yaml_plan/step/verbose.rb
 - lib/bolt/pal/yaml_plan/transpiler.rb
 - lib/bolt/plan_creator.rb
 - lib/bolt/plan_future.rb

data/guides/debugging.txt

@@ -1,28 +0,0 @@
-TOPIC
-    debugging
-
-DESCRIPTION
-    When Bolt isn't behaving as expected, there are a few helpful commands and
-    logs that can help identify common issues. The first place to look is in
-    `<PROJECT>/bolt-debug.log`, which contains debug-level logs from the last Bolt
-    run. This log file includes where the Bolt project was loaded from, the
-    location of any configuration or inventory files that were loaded, and the
-    modulepath that modules were loaded from.
-
-    If you're having issues with loading targets or target configuration, you
-    can see the list of resolved Bolt target names by running `bolt inventory
-    show` on *nix systems or `Get-BoltInventory` in PowerShell. To see the
-    resolved configuration for each target, run the command with the `--detail` or
-    `-Detail` options.
-
-    Lastly, if you're having trouble loading Bolt content you can use `bolt
-    module show` on *nix systems or `Get-BoltModule` in PowerShell to see the list
-    of loaded modules, including where they were loaded from. You can also use
-    `bolt task show` or `Get-BoltTask` to list loaded tasks, and `bolt plan show`
-    or `Get-BoltPlan` to list loaded plans.
-
-    Visit the linked documentation for more in-depth troubleshooting help for
-    specific issues.
-
-DOCUMENTATION
-    https://pup.pt/bolt-troubleshooting

data/guides/guide.txt

@@ -1,17 +0,0 @@
-TOPIC
-    guide
-
-DESCRIPTION
-    A guide is a person (or CLI tool ;D) who leads travelers through unknown or
-    unfamiliar locations. The term can also be applied to a person who leads others
-    to more abstract goals such as knowledge or wisdom. 
-
-    Etymology: Originated sometime between 1325 and 1375. From Middle English
-    guide, from the Old French guide, from Old Occitan guida, from guidar, from
-    Frankish *wītan (“to show the way, lead”), from Proto-Germanic *wītaną (“to
-    see, know; go, depart”), from Proto-Indo-European *weyd- (“to see, know”).
-    Related also to English wit. 
-
-DOCUMENTATION
-    https://en.wikipedia.org/wiki/Guide
-    https://en.wiktionary.org/wiki/guide

data/guides/inventory.txt

@@ -1,24 +0,0 @@
-TOPIC
-    inventory
-
-DESCRIPTION
-    The inventory describes the targets that you run Bolt commands on, along
-    with any data and configuration for the targets. Targets in an inventory can
-    belong to one or more groups, allowing you to share data and configuration
-    across multiple targets and to specify multiple targets for your Bolt
-    commands without the need to list each target individually.
-
-    In most cases, Bolt loads the inventory from an inventory file in your Bolt
-    project. The inventory file is a YAML file named 'inventory.yaml'. Because
-    Bolt loads the inventory file from a Bolt project, you must have an existing
-    project configuration file named 'bolt-project.yaml' alongside the inventory
-    file.
-
-    When Bolt loads inventory, it loads the entire inventory, not just the
-    groups and targets specified on the command line. If you've defined a
-    target in multiple groups, this might result in target configuration that
-    is different than expected.
-
-DOCUMENTATION
-    https://pup.pt/bolt-inventory
-    https://pup.pt/bolt-inventory-reference

data/guides/links.txt

@@ -1,13 +0,0 @@
-TOPIC
-    links
-
-DESCRIPTION
-    Bolt documentation          https://bolt.guide
-    Ask a question in #bolt     https://slack.puppet.com/
-    Contribute at               https://github.com/puppetlabs/bolt/
-    Getting Started Guide       https://pup.pt/bolt-getting-started
-    Reference Documentation     https://pup.pt/bolt-reference
-    Troubleshooting Bolt        https://pup.pt/bolt-troubleshooting
-    Bolt Developer Updates      https://pup.pt/bolt-dev-updates
-    Bolt Changelog              https://pup.pt/bolt-changelog
-    Bolt Examples               https://pup.pt/bolt-examples

data/guides/logging.txt

@@ -1,18 +0,0 @@
-TOPIC
-    logging
-
-DESCRIPTION
-    Bolt prints messages both to the console and to log files. Messages can
-    either come from Bolt's 'outputter', which logs user-facing messages like
-    progress and results, or from the 'logger', which logs warnings, errors, and
-    log-structured output to log files. Both of these message streams are
-    configurable.
-
-    By default, Bolt logs to the console at 'warn' level and writes a log file to
-    '<project>/bolt-debug.log' at 'debug' level. Unless you are running a plan,
-    Bolt runs in verbose mode by default.
-
-    To learn more about projects, see the 'project' guide.
-
-DOCUMENTATION
-    https://pup.pt/bolt-logging

data/guides/module.txt

@@ -1,19 +0,0 @@
-TOPIC
-    module
-
-DESCRIPTION
-    Modules are shareable, reusable packages of Puppet content. They can include
-    tasks, plans, functions, and other types of content that you can use in your
-    project. You can download and install modules to your project from the
-    Puppet Forge or write your own modules. Bolt also ships with several helpful
-    modules pre-installed that are available to all of your projects.
-
-    Bolt makes it easy to manage the modules that your project depends on. You
-    can use Bolt commands to install a project's modules, add new modules to a
-    project, and view the modules that are available to the project.
-    
-    To learn more about managing modules in a project, see the documentation.
-    To learn how modules are loaded by Bolt, see the 'modulepath' guide.
-
-DOCUMENTATION
-    https://pup.pt/bolt-modules

data/guides/modulepath.txt

@@ -1,25 +0,0 @@
-TOPIC
-    modulepath
-
-DESCRIPTION
-    The modulepath is an ordered list of directories that Bolt loads modules
-    from. When Bolt runs a command, it automatically loads modules from the
-    modulepath.
-    
-    While Bolt has a default modulepath, you can also configure your own
-    modulepath, which can include directories within the project or directories
-    elsewhere on your system. Regardless of whether your project uses a default
-    or configured modulepath, Bolt automatically adds directories to the
-    modulepath. This includes modules containing core Bolt content, which is
-    added to the beginning of the modulepath, and bundled content, which is
-    added to the end of the modulepath.
-
-    Modules loaded from a directory listed earlier in the modulepath take
-    precedence over modules with the same name loaded from a directory later in
-    the modulepath. Bolt will not warn or error when two modules share a name
-    and instead will ignore modules with a lower precedence.
-
-    To learn more about modules, see the 'module' guide.
-
-DOCUMENTATION
-    https://pup.pt/bolt-project-reference#modulepath

data/guides/project.txt

@@ -1,22 +0,0 @@
-TOPIC
-    project
-
-DESCRIPTION
-    A Bolt project is a directory that serves as the launching point for Bolt
-    and allows you to create a shareable orchestration application. Projects
-    typically include a project configuration file, an inventory file, and any
-    content you use in your project workflow, such as tasks and plans.
-
-    When you run Bolt, it runs in the context of a project. If the directory you
-    run Bolt from is not a project, Bolt attempts to find a project by
-    traversing the parent directories. If Bolt is unable to find a project, it
-    runs from the default project, located at '~/.puppetlabs/bolt'.
-
-    A directory is only considered a Bolt project when it has a project
-    configuration file named 'bolt-project.yaml'. Bolt doesn't load project data
-    and content, including inventory files, unless the data and content are part
-    of a project.
-
-DOCUMENTATION
-    https://pup.pt/bolt-projects
-    https://pup.pt/bolt-project-reference

data/guides/targets.txt

@@ -1,29 +0,0 @@
-TOPIC
-    targets
-
-DESCRIPTION
-    A target is a device that Bolt connects to and runs actions on. Targets can
-    be physical, such as servers, or virtual, such as containers or virtual
-    machines.
-
-    Several of Bolt's commands connect to targets and run actions on them.
-    These commands require a target or targets to run on. You can specify
-    targets to a command using one of the following command-line options:
-
-    *nix options                Powershell options
-     -t, --targets TARGETS      -T, -Targets  TARGETS
-     -q, --query   QUERY        -Q, -Query    QUERY
-         --rerun   FILTER       -Rerun        FILTER
-
-    The 'targets' option accepts a comma-separated list of target URIs or group
-    names, or can read a target list from an input file '@<file>' or stdin '-'.
-    URIs can be specified with the format [protocol://][user@]host[:port]. To
-    learn more about available protocols and their defaults, run 'bolt guide
-    transports'.
-
-    Typically, targets and their configuration and data are listed in a
-    project's inventory file. For more information about inventory files,
-    see 'bolt guide inventory'.
-
-DOCUMENTATION
-    https://pup.pt/bolt-commands

data/guides/transports.txt

@@ -1,23 +0,0 @@
-TOPIC
-    transports
-
-DESCRIPTION
-    Bolt uses transports (also known as protocols) to establish a connection
-    with a target in order to run actions on the target. The default transport is
-    SSH, and you can see available transports along with their configuration
-    options and defaults at http://pup.pt/bolt-reference.
-
-    You can specify a transport for a target by prepending '<transport>://' to
-    the target's URI. For example, to connect to a target with hostname
-    'example.com' as user 'Administrator' using the WinRM transport, you would
-    pass the following to the target flag:
-        winrm://Administrator@example.com
-
-    You can also specify a default transport for all targets by passing the
-    '--transport' flag on *nix systems and the '-Transport' flag in Powershell.
-    Finally, you can set the transport for a target in the inventory. For more
-    information about the Bolt inventory, run 'bolt guide inventory'.
-
-DOCUMENTATION
-    https://pup.pt/bolt-commands#specify-a-transport
-    http://pup.pt/bolt-inventory#transport-configuration