v0.5.0

This release brings improvements and new features to improve the experience of authoring custom rules, as well as new, granular capabilities for ignoring files. Most of these improvements are directly based on feedback — and in some cases contributions — from Regal users, which is particularly exciting!

New functionality for ignoring files at a global level and rule level

In addition to setting the severity level of a rule in the Regal configuration file, it is now possible to have the linter ignore files based on their name (or a pattern). This configuration can be applied either globally for all rules, or per rule. An example of this could be wanting to allow the use of the print function in files with a _test.rego suffix, but not in any other files.

Example .regal/config.yaml

ignore:
  files:
    # ignore this file for all rules
    - sketch.rego
rules:
  testing:
    print-or-trace-call:
      level: error
      ignore:
        files:
          # ignore the print-or-trace-call rule in tests
          - "*_test.rego"

See the configuration section of the docs for more details. Thanks @kristiansvalland for this excellent contribution!

Custom rules authoring improvements

Based on feedback we got from users starting to write their own custom rules, we've made several updates to the docs on this topic, fixing the parts people found confusing, and added more examples show e.g. the directory structure of a policy repo using custom Regal rules. Apart from documentation, we've also made it possible have custom rules without a related_resources attribute in the metadata, as some might prefer to document their rules in code, or by other means.

Enhanced type checking of the input AST

This improves the authoring experience for both builtin and custom rules. The regal test command, which is commonly used when developing and testing new rules, now makes use of a schema for the input attribute, i.e. the AST. This allows the command to fail directly when unknown attributes on input are encountered in linter rules, due to typos or other mistakes.

To use this schema in custom rules, add a schemas attribute to the package annotation, using schema.regal.ast for the input:

# METADATA
# description: All packages must use "acme.corp" base name
# schemas:
# - input: schema.regal.ast
package custom.regal.rules.naming["acme-corp-package"]

import future.keywords.contains
import future.keywords.if

report contains violation if {
    # this will fail at compile time, as there is no 'functions' attribute
    # in the input AST
    some function in input.functions

    # ...
}

The schema is applied automatically for builtin rules.

Community

On the community side, we're excited to have @kristiansvalland join us as a maintainer!

Changelog

• 698c78e: Remove if rule comment, already in another file (#194) (@charlieegan3)
• 88757dc: ci/build: run on PRs (#198) (@srenatus)
• 59d0682: Add Regal bundle to test cmd runner (#197) (@kristiansvalland)
• 79b5434: Some README fixes (#195) (@anderseknert)
• 22943e7: Fix docs in custom-has-key-construct (#203) (@anderseknert)
• 42878a3: Fix unused-return-value config attribute (@anderseknert)
• 462ba0a: Enhanced type checking using Regal AST schema (#201) (@anderseknert)
• c35a1ab: Improve docs on custom rules authoring (#205) (@anderseknert)
• 7d46fc6: Update config.yaml example (#209) (@charlieegan3)
• 9bdbe30: Add functionality for ignoring files at a global level and rule level. (#200) (@kristiansvalland)
• 6fdb963: Custom rules may skip related_resources (#210) (@anderseknert)