Epic Goal

Enhance the tech-preview policy linter created last release. There are several more ideas for linter rules we can implement, and space for more ideas to come up from the forum help threads. In addition, we should explore making it more usable inside of code editors, as opposed to just through the separate CLI.

Why is this important?

Templating is the primary value point for the ACM / Open Cluster Management policy engine; however we frequently encounter users having challenges with developing and testing their templating. A linter will help reduce the workflow loop around developing policies, allowing users to be more productive.

Scenarios

...

Acceptance Criteria

...

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. ...

Open questions:

1. …

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub
  Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub
  Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Doc issue opened with a completed template. Separate doc issue
  opened for any deprecation, removal, or any current known
  issue/troubleshooting removal from the doc, if applicable.
• Considerations were made for Extended Update Support (EUS)