microsoft / PSRule

Validate infrastructure as code (IaC) and objects using PowerShell rules.
https://microsoft.github.io/PSRule/v2/
MIT License
385 stars 49 forks source link

Allow rules to be versioned #787

Closed BernieWhite closed 2 years ago

BernieWhite commented 3 years ago

Currently each rule can be created and updated. While rules can be named independently to identify the version of the rule there is no explicit support for versioning a rule and selecting a rule version.

For example:

Rule 'Rule1' -Version 1 {
    # implementation
}
---
apiVersion: github.com/microsoft/PSRule/v1
kind: Rule
metadata:
  name: Rule1
  version: 1
spec: { }

Rule Id would be updated to be .\Rule1@1 or Module\Rule1@1.

Potentially a semver version could be used. but there may be little or no benefits if we assume semver that a minor or patch versions are backward compatible. If this is true, why would a separate rule with a minor or patch version increment be created?

When using rules in baselines, by name or dependency we need to have a consistent behaviour about selecting the rule version, like select the latest unless specified.

BernieWhite commented 2 years ago

@ArmaanMcleod Thoughts?

Working through this. I don't feel there is a good enough use case for this currently.

If you look at other static analysis tools such as Roslyn, ESLint, or PSScriptAnalyzer there is not concept of rule versioning. It's either a rule or not. New rules have a new name/ ID.

To round out the PSRule implementation we may want to implement marking a rule as disabled or obsolete.

ArmaanMcleod commented 2 years ago

@ArmaanMcleod Thoughts?

Working through this. I don't feel there is a good enough use case for this currently.

If you look at other static analysis tools such as Roslyn, ESLint, or PSScriptAnalyzer there is not concept of rule versioning. It's either a rule or not. New rules have a new name/ ID.

To round out the PSRule implementation we may want to implement marking a rule as disabled or obsolete.

@BernieWhite I've also thought about this as well and struggle to see a practical usecase.

For me atleast I would probably not add versions to my rules since it would get difficult to manage them and make sure minor and patch versions are backwards compatible, assuming semantic versioning is used.

If we had two rules like Rule@1 and Rule@1.1, would both versions be stored in code? I would assume so given the user could invoke an older rule(latest fetched by default) and they would need to be referenced from somewhere. I feel like most people wouldn't be bothered to do that and keep all rules at version 1(or no version).

One situation I could see this being useful is not requiring new rule versions to be added incrementally to the name like MyRule, MyRuleV2 etc. where the user would want to maintain a similar rule name and add the version themselves. Having the capability to instead add a version to the rule instead means rule names could be duplicated, but uniquely identified by rule version. I guess this is where this differs from the other static analysis rules you mentioned, since any new rules would just be created with a new name and having duplicate rule names is not an option.

Perhaps we could open a discussion and see if anyone would find this useful?

BernieWhite commented 2 years ago

@ArmaanMcleod Good idea.