Return EvalResults from rego constraints evaluation

[eleftherias]

Summary

Output the list of violations from the rego constraints evaluation engine.
This lets us use the violations in the pull_request_comment alert type.
For example, when using the json violation format:

  eval:
    type: rego
    rego:
      type: constraints
      violation_format: json
      def: |
        package minder

        import future.keywords.in
        import future.keywords.if

        # For demo purposes: create a violation for every file
        violations[{"msg": msg}] if {
          files_in_repo := input.ingested.files

          some current_file in files_in_repo
        
          msg := sprintf("File found: %s", [current_file.name])
        }
  alert:
    type: pull_request_comment
    pull_request_comment:
      review_message: |
        {{- range .EvalResultOutput }}  
        - {{ .msg }}
        {{- end }}

Or for the default, text violation format:

  eval:
    type: rego
    rego:
      type: constraints
      def: |
        package minder

        import future.keywords.in
        import future.keywords.if

        # For demo purposes: create a violation for every file
        violations[{"msg": msg}] if {
          files_in_repo := input.ingested.files

          some current_file in files_in_repo
        
          msg := sprintf("File found: %s", [current_file.name])
        }
  alert:
    type: pull_request_comment
    pull_request_comment:
      review_message: |
        {{- range .EvalResultOutput }}  
        - {{ .}}
        {{- end }}

Ref #5024

Change Type

Mark the type of change your PR introduces:

• Bug fix (resolves an issue without affecting existing features)
• Feature (adds new functionality without breaking changes)
• Breaking change (may impact existing functionalities or require documentation updates)
• Documentation (updates or additions to documentation)
• Refactoring or test improvements (no bug fixes or new functionality)

Testing

Outline how the changes were tested, including steps to reproduce and any relevant configurations.
Attach screenshots if helpful.

Review Checklist:

• Reviewed my own code for quality and clarity.
• Added comments to complex or tricky code sections.
• Updated any affected documentation.
• Included tests that validate the fix or feature.
• Checked that related changes are merged.

[coveralls]

coverage: 55.364% (-0.01%) from 55.374%
when pulling 0cac0c9 on eleftherias:rego-constraints-return-eval-result
into 5e3b3c8 on mindersec:main.

[blkt]

LGTM, but I'd let others chime in as well.

[evankanderson]

Maybe just a TODO, but should we return message and entity name as an evaluation result in the future?

(We may want to think about the format here, I'm not sure)

[blkt]

This was a requirement for improved evaluation details story, but the request was discussed via Slack IIRC.

[eleftherias]

I agree, I wanted to start with the constraints engine because that's what the Trusty rule will use, but the deny-by-default engine will be updated too.

[evankanderson]

In the future, should we feed the Output from the first argument into the Template for the EvaluationError, rather than duplicating between the two?

(That should definitely be a follow-up issue)

[eleftherias]

Yes, we should also use the EvaluationError for actual unexpected errors and the EvaluationResult for failures.

[evankanderson]

Would it make sense to have Output: []any{} here, or will Output being nil be handled the same as an empty list?

[eleftherias]

It will be handled the same as an empty list. I tested it in go code and in the template rendering, is there some other scenario I should check?

[evankanderson]

No, this was just a question I was too lazy to check myself. 😁