Skip to content

v0.8.0
Compare
Choose a tag to compare
@github-actions github-actions released this 04 Sep 11:29
· 719 commits to main since this release
v0.8.0
6253cae
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Verified
Learn about vigilant mode.

This is the most feature-packed release to date, adding a new output format, four new rules, and many improvements across the board!

New GitHub output format

The regal lint command now accepts a new --format option named github. This is ideal for when Regal is run in CI/CD scenarios using GitHub Actions. This format will emit annotations for any violation, which will be visible in the pull request file view.

annotation

In addition to this, the GitHub output format will also create a linter report visible in the "Checks" tab:

report

This report summarizes the result of linting, with links provided to the documentation for any violation.

New rule: use-some-for-output-vars

Category: idiomatic

Using some to declare output variables used in iteration (and elsewhere) has long been considered a best practice. Regal can now identify places where variables are introduced without some and treat these as errros:

allow {
    userinfo := data.users[id]
    # ...
}

Unless the id variable in the above example is declared elsewhere in the policy, it should be declared using some:

allow {
    some id
    userinfo := data.users[id]
    # ...
}

# alternatively, and arguably more idiomatic:
allow {
    some id, userinfo in data.users
    # ...
}

For more information, see the docs on use-some-for-output-vars.

New rule: prefer-some-in-iteration

Category: style

Similarly, the new prefer-some-in-iteration rule will have Regal warn when using the "old" style of iteration which could be replaced in favor of some ... in:

engineers[employee] {
    employee := data.employees[_]
    employee.role in engineering_roles
}

# Prefer some .. in

engineers[employee] {
    some employee in data.employees
    employee.role in engineering_roles
}

An exception to this rule may deeply nested iteration, where the shorter syntax is often preferable. Regal thus allows configuring the rule to allow exceptions from any given nesting level.

For more information, see the docs on prefer-some-in-iteration.

New rule: metasyntactic-variable

Category: testing

Using rule and variable names like "foo", "bar" or "baz" might be convenient in examples, but rarely has a place in production policy. The new metasyntactic-variable rule will flag any occurences of these names. The ignore directive may of course be used to e.g. allow these type of variables in tests or other legitimate locations.

For more information, see the docs on metasyntactic-variable.

New rule: file-length

Category: style

Having policy files span several hundred lines of code is often a signal to consider refactoring the code into smaller units, and to modularize properly using packages and imports. The new file-length rule by default flags any file with more than 500 lines. This number can be changed via the rule's configuration.

For more information, see the docs on file-length.

Other improvements

In addition to the above features, this release comes with many smaller improvements to code, documentation and the pre-commit-hooks — not to mention a bunch of bugs that got fixed. Thanks to everyone who contributed to this release!

Changelog

Contributors

mcguiresm, anderseknert, and 5 other contributors
Assets 8
Loading