Update Jig docs for the move to voxpupuli/jig and refresh to current CLI

PDK.markdown

@@ -6,7 +6,7 @@
 
 The **Puppet Development Kit (PDK)** is a package of development and testing tools that helps you create, validate, and test Puppet modules.
 
 > **Note:** Puppet (Perforce) ceased open-source maintenance of PDK at version **3.4.0**. Newer versions are distributed from a protected repository requiring either a Puppet Forge API key or a Puppet Enterprise license ID to download; see [Puppet's PDK documentation](https://help.puppet.com/pdk/current/topics/pdk.htm) for details. Documentation for the last open-source release is available in the [pdk repository on GitHub](https://github.com/puppetlabs/pdk/blob/main/docs/pdk.md).
 
 ## Overview
 
@@ -25,5 +25,5 @@
 
 The OpenVox community maintains tooling that replaces PDK workflows without requiring a commercial Puppet account:
 
 - **[VoxBox](https://github.com/voxpupuli/container-voxbox)** — A container image maintained by Vox Pupuli that includes rspec-puppet, Litmus, RuboCop, and other testing gems. It is the recommended way to run unit and acceptance tests for OpenVox modules in CI and local development.
-- **[jig](https://github.com/avitacco/jig)** — A Go-based reimplementation of PDK. Ships as a single static binary with no Ruby runtime dependency and supports module scaffolding, building, and releasing.
+- **[Jig](/ecosystem/latest/devkit/jig.html)** — A Go-based reimplementation of PDK. Ships as a single static binary with no Ruby runtime dependency and supports module scaffolding, building, and releasing. See the [jig project on GitHub](https://github.com/voxpupuli/jig) for source and releases.

_data/nav/openvox_8x.yml

@@ -99,6 +99,8 @@
     link: "modules_fundamentals.html"
   - text: Beginner's guide to writing modules
     link: "bgtm.html"
+  - text: Scaffolding modules with Jig
+    link: "/ecosystem/latest/devkit/jig.html"
   - text: Plugins in modules
     link: "plugins_in_modules.html"
   - text: Installing modules

docs/_ecosystem_8x/devkit/components.md

@@ -7,9 +7,10 @@ The Vox Pupuli developer toolkit is spread amongst many Ruby gems and other tool
 Most will be automatically pulled in via Bundler and the `Gemfile`, and some of the main ones will be listed at the bottom of this page for convenience.
 We'll focus on the tools that you may want to be aware of and install or use directly.
 
-* [Jig](https://github.com/avitacco/jig) is useful for scaffolding content for new and existing modules.
+* [Jig](https://github.com/voxpupuli/jig) is useful for scaffolding content for new and existing modules.
   All content it generates includes the appropriate barebones unit tests ready for you to fill out.
   It can also publish modules to the Puppet Forge.
+  See [Scaffolding New Content with Jig](jig.html) for installation and usage.
 * [ModuleSync](https://github.com/voxpupuli/modulesync) helps maintain a portfolio of many modules at once.
   It does this by maintaining both common static files (like contributing guides, licenses, or testing boilerplate) as well as templated files like `metadata.json` across multiple module repositories.
   This allows you to keep them all in a consistent state with minimal fuss.

docs/_ecosystem_8x/devkit/jig.md

@@ -13,11 +13,11 @@ While OpenVox can technically load content this way in some cases, it's best to
 
 It's possible to create files and maintain the proper directory structure by hand and nothing prevents you from doing so.
 However, many people today prefer to use a scaffolding tool to maintain proper structure and consistency.
-The tool we recommend for this today is [Jig](https://github.com/avitacco/jig).
+The tool we recommend for this today is [Jig](https://github.com/voxpupuli/jig).
 
 ## Installing Jig
 
-Download the latest release for your platform from the [releases page](https://github.com/avitacco/jig/releases).
+Download the latest release for your platform from the [releases page](https://github.com/voxpupuli/jig/releases).
 Uncompress it and move the `jig` binary to a path like `/usr/local/bin`.
 
 {% include alert.html type="tip" title="macOS Security Alert" content="The packages are unsigned, so macOS won't open them by default. Run it once and cancel the warning dialog that tells you to trash it.
@@ -29,7 +29,7 @@ This will place the compiled binary into `$GOPATH/bin`, which is likely to be `~
 Ensure that location is in your `$PATH`.
 
 ```console
-go install github.com/avitacco/jig@latest
+go install github.com/voxpupuli/jig@latest
 ```
 
 ## Creating a new module
@@ -47,6 +47,9 @@ Source URL for the module []: https://http.cat/status/404
 Created new module demo in /Users/ben.ford/Projects/demo
 ```
 
+To skip the interview and take the values from your config file, flags, or defaults instead, pass `--skip-interview` (or `-i`).
+You can supply individual values with flags such as `--forge-user`, `--author`, `--license`, `--summary`, and `--source`.
+
 Jig will create the full directory structure with starter files for the main class, Hiera data, rspec initialization helpers, etc.
 
 ```console
@@ -123,7 +126,7 @@ Jig can create other types of content for your module:
 * `transport` _(uncommon)_
   * Creates a new [Resource API](https://github.com/puppetlabs/puppet-resource_api) transport and its associated files.
 
-See [Jig's GitHub page](https://github.com/avitacco/jig) for full documentation.
+See [Jig's GitHub page](https://github.com/voxpupuli/jig) for full documentation.
 
 ## Configuring Jig
 
@@ -148,7 +151,12 @@ To customize them, you'd dump them to disk and then edit as you like.
 jig templates dump ~/.config/jig/templates
 ```
 
-To use your new templates, add this directory to your Jig config file.
+Any template found in your directory takes precedence over the embedded default, and any template you don't override falls back to the embedded version, so you only need to include the files you want to change.
+
+To tell Jig where your templates live, use either of the following:
+
+* the `--template-dir` (`-t`) flag on `jig new`, which takes precedence, or
+* the `template_dir` key in your Jig config file.
 
 -----
 

docs/_ecosystem_8x/devkit/linting.md

@@ -31,6 +31,9 @@ manifests/init.pp:10:manifest_whitespace_double_newline_end_of_file:ERROR:there
 Try running the `lint_fix` task instead and you'll see most or all of the offenses marked as `FIXED` instead of `ERROR` or `WARNING` indicating that it has fixed the source files for you.
 Some offenses cannot be fixed automatically and you may have to update them yourself.
 
+If you use Jig, `jig validate` runs the `validate` and `lint` tasks together (equivalent to `bundle exec rake validate lint`).
+It doesn't run `lint_fix`, so run the `lint_fix` task directly when you want automatic fixes.
+
 ### Configuring the Puppet linter
 
 You can disable any of the checks you like by creating a `.puppet-lint.rc` file in the root of your module.

docs/_ecosystem_8x/devkit/migrating.md

@@ -16,15 +16,18 @@
 
 {% include alert.html type="tip" content="There are a few exceptions to this pattern. For example, Jig is an installed package and VoxBox is a Docker container." %}
 
-| You used to type... | Now you type...                  |
-|---------------------|----------------------------------|
-| `pdk new module`    | `jig new module`                 |
-| `pdk new class`     | `jig new class`                  |
-| `pdk build`         | `jig build`                 |
-| `pdk release`       | `jig release`                    |
-| `pdk convert`       | _not needed_                     |
-| `pdk update`        | `bundle exec msync update`       |
-| `pdk validate`      | `bundle exec rake validate lint` |
-| `pdk test unit`     | `bundle exec rake spec`          |
+| You used to type... | Now you type...  |
+|---------------------|------------------|
+| `pdk new module`    | `jig new module` |
+| `pdk new class`     | `jig new class`  |
+| `pdk build`         | `jig build`      |
+| `pdk release`       | `jig release`    |
+| `pdk convert`       | _not needed_     |
+| `pdk update`        | `jig update`     |
+| `pdk validate`      | `jig validate`   |
+| `pdk test unit`     | `jig test unit`  |
+
+`jig update`, `jig validate`, and `jig test unit` are thin wrappers around `bundle exec msync update`, `bundle exec rake validate lint`, and `bundle exec rake spec` respectively, so they still need the module's gems installed (`bundle install`).
+You can keep running the underlying `bundle exec` commands directly if you prefer.
 
 Browse through the individual subpages of this Developer Tooling section to learn more about each component.

docs/_ecosystem_8x/devkit/unit_testing.md

@@ -49,6 +49,9 @@ end
 
 This uses [`facterdb`](https://github.com/voxpupuli/facterdb) and [`rspec-puppet-facts`](https://github.com/voxpupuli/rspec-puppet-facts) to run your the test on all supported platforms from the module's `metadata.json`.
 
+To run your unit tests, use `jig test unit`, which wraps `bundle exec rake spec`.
+Either form needs the module's gems installed, so run `bundle install` first.
+
 If you'd like to constrain a test run to only a specific OS or OS release, you can do so with environment variables:
 
 ```console

docs/_openvox_8x/modules_publishing.markdown

@@ -73,7 +73,7 @@
 
 To do this, you'll exclude unnecessary files from your package or repository, remove or ignore any symlinks your module contains, and make sure your `metadata.json` contains the correct information.
 
 {% include alert.html type="note" content="In order to successfully publish your module to the Puppet Forge and ensure that everything is rendered correctly, your `README`, license file, changelog, and `metadata.json` must be UTF-8 encoded.
 If you used modern tooling to create your module, these files are already UTF-8 encoded." %}
 
 
@@ -103,11 +103,11 @@
 tmp/
 ```
 
-The `.pdkignore` file excludes files during `jig module build` only.
+The `.pdkignore` file excludes files during `jig build` only.
 For example, you might want spec tests in your source control but not in your module package, so you would list them in `.pdkignore`.
 To prevent files, such as those in temporary directories, from ever being checked into Git, use `.gitignore`.
 
-If you have both a `.pdkignore` and a `.gitignore` file, the `jig module` command uses the `.pdkignore` file.
+If you have both a `.pdkignore` and a `.gitignore` file, the `jig build` command uses the `.pdkignore` file.
 
 ### Removing symlinks from your module
 
@@ -143,7 +143,7 @@
 
 To upload your module to the Forge, you first must build the module package.
 
-1. From the command line in your module's root directory, run `jig build build`. This command generates a `.tar.gz` package and saves it in the module's `pkg/` subdirectory.
+1. From the command line in your module's root directory, run `jig build`. This command generates a `.tar.gz` package and saves it in the module's `pkg/` subdirectory.
 
    For example:
 
@@ -163,7 +163,7 @@
 
 2. Click **Publish** in the upper right hand corner of the screen.
 
 4. On the upload page, click **Choose File** and use the file browser to locate and select the release tarball. Then click **Upload Release**.
 
 After a successful upload, your browser should load the new release page of your module, with any errors popping up on the same screen.
 Your module's README, Changelog,and License files are displayed on your module's Forge page.
@@ -177,13 +177,13 @@
 
    * The full name of the module to be deprecated, such as `puppetlabs-apache`.
    * Optionally, the reason for the deprecation. The reason will be publicly displayed on the Forge.
     * Optionally, a recommended alternative module or workaround.
 
 ## Delete a module release from the Forge
 
 If you want to delete a release of your module, you can do so from the Forge's web interface.
 
 A deleted release is still downloadable via the Forge page or `puppet module` command if a user requests the module by specific version. **You cannot delete a released version and upload a new version of the same release.**
 
 1. In your web browser, navigate [to the Puppet Forge][forge] and log in.