Skip to content

What's new in v3#

Welcome to the v3 release of PSRule. There are many updates in this version that we hope you'll like, some of the key highlights include:

See the detailed change log here.

Official CLI support#

While many of you have been using PSRule through PowerShell for some time, we've been working on a new experience for those who prefer a CLI.

Additionally, we wanted to improve the bootstrapping experience for PSRule in during development and CI/CD pipelines.

The new CLI runs on Windows, macOS, and Linux and is available as a standalone executable or can be installed as a .NET tool.

Continue reading CLI to learn more.

Module lock file#

We've introduced a new feature to help you manage the versions of modules used by PSRule. The module lock file is a JSON-based file named ps-rule.lock.json that lists the modules and versions used by PSRule. Initialize and commit the lock file to your repository to pin each module to a specific version.

If the lock file is present, PSRule will use the versions listed in the lock file instead of the latest available version. When no lock file is present, PSRule will use the latest version of each module that meets any configured constraints.

This makes it easier to share and reproduce the versions of modules used during development and CI/CD pipelines.

This is an example of the lock file used for the PSRule repository:

ps-rule.lock.json
{
  "version": 1,
  "modules": {
    "PSRule.Rules.MSFT.OSS": {
      "version": "1.1.0",
      "integrity": "sha512-4oEbkAT3VIQQlrDUOpB9qKkbNU5BMktvkDCriws4LgCMUiyUoYMcN0XovljAIW4FO0cmP7mP6A8Z7MPNGlgK7Q=="
    }
  }
}

This is a change to the previous behavior in CI/CD pipelines where PSRule:

  • Would install the latest version of each module but only if no version was not already installed.
  • Would not check if the installed version met constraints defined in the options file.

The lock file is supported by the CLI, GitHub Actions, Azure Pipelines, and Visual Studio Code extension. When using PSRule from PowerShell, the lock file is ignored to prevent conflicts with PowerShell's built-in update mechanism.

Continue reading Lock file to learn more.

Visual Studio Code#

New home and identity#

The Visual Studio Code (VSCode) extension for PSRule now lives side-by-side with core components of PSRule on GitHub.

As part of this change we are now publishing the extension as a verified Microsoft extension with the ID ps-rule.vscode-ps-rule.

The new extension supports pre-release and stable releases managed through Visual Studio Code's extension marketplace.

We hope this will not only help the community to log issues and get help on the correct repository, but also streamline how we deliver updates in the future.

Bringing together the code base is the first step in building an all improved rich experience in VSCode for PSRule.

Runtime integration#

Previously to use PSRule within VSCode, a prerequisite step was to install PowerShell on non-Windows OSs and then install PSRule through PowerShell. Additionally, any required rules modules would also need to be installed through PowerShell.

We've done away with this approach entirely for the authoring experience in VSCode by providing native support in the extension.

This means you can now use PSRule in VSCode without needing to separately install PowerShell or PSRule on your machine. The extension includes the necessary components to run PSRule and will install and cache required rule modules.

We've improved the experience by adding the ability to:

  • Restore modules from the VSCode command palette.
  • Asking to automatically restore required modules when you open a workspace that contains a PSRule lock file.

Formats and emitters#

For a while now, we've wanted to improve how PSRule handles input files to make it easier to work with new formats. PSRule has supported JSON, YAML, Markdown, and PowerShell data files for some time. However adding support for new types of files required changes to the core engine.

We've introduced a new format and emitter API to make it easier to add support for new formats outside the core engine. While workarounds were possible, they were hard to scale when working with large repositories.

This means you can now write emitters for additional or custom formats and use them with PSRule shipped within a module.

Additionally, we added the following features:

  • Multiple formats can be used in a single PSRule run.
  • The file types associated with each format can be configured as an option.
  • Replacement strings can be configured to automatically replace literal values in input files during processing.

For example, the following configuration:

  1. Enables the JSON format.
  2. Replaces the {{environment}} string with production in input files.
ps-rule.yaml
format:
  json:
    enabled: true
    replace:
      '{{environment}}': production

Continue reading Formats and emitters to learn more.

Other minor features and improvements#

  • You can now override the options file that VSCode uses when running PSRule.
    • Previously only ps-rule.yaml was used by VSCode although PSRule generally supported changing the options file.

Comments