Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Read the Pi hostname from config instead of rule_type #1313

Merged
merged 2 commits into from
Oct 30, 2023
Merged

Read the Pi hostname from config instead of rule_type #1313

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
50471f8
Don't specify the Pi server explicitly in rule_type, rely on config d…
jhrozek Oct 27, 2023
086879a
If the pr_package_intelligence_check doesn't specify an endpoint, use…
jhrozek Oct 30, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 1 addition & 2 deletions examples/github/rule-types/pr_package_intelligence_check.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -49,5 +49,4 @@ def:
# Defines the configuration for evaluating data ingested against the given profile
eval:
type: package_intelligence
package_intelligence:
endpoint: https://staging.stacklok.dev/
package_intelligence: {}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unrelated, but should we rename the evaluator to trusty?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably, yes. You can do it now or in the big rename.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we're squashing PRs I would prefer a separate PR - otherwise this PR that adds a single env variable would /also/ rename a bunch of identifiers and it would be too hard to search git history.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and I was asking explicitly because I think this is too easy to miss in the big rename - I assume that whoever is doing the big rename would be looking for mediator, but not necessarily for package_intelligence.

9 changes: 7 additions & 2 deletions internal/engine/eval/eval.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,7 @@ package eval

import (
"fmt"
"os"

"github.com/stacklok/mediator/internal/engine/eval/jq"
"github.com/stacklok/mediator/internal/engine/eval/package_intelligence"
Expand Down Expand Up @@ -49,10 +50,14 @@ func NewRuleEvaluator(rt *pb.RuleType, cli *providers.ProviderBuilder) (engif.Ev
case vulncheck.VulncheckEvalType:
return vulncheck.NewVulncheckEvaluator(e.GetVulncheck(), cli)
case package_intelligence.PiEvalType:
if rt.Def.Eval.GetPackageIntelligence() == nil {
pie := e.GetPackageIntelligence()
if pie == nil {
return nil, fmt.Errorf("rule type engine missing package_intelligence configuration")
}
return package_intelligence.NewPackageIntelligenceEvaluator(e.GetPackageIntelligence(), cli)
if pie.GetEndpoint() == "" {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm confused on how this is getting used -- it looks like we're getting pie from rt.Def.Eval, modifying the returned result (maybe it's a pointer?), and then passing e's package intelligence.

Should this be using e.GetPackageIntelligence()?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, I should have passed in pie. Thanks for noticing that. But in this specific case, it doesn't matter, because rt.Def.Eval is a pointer to a protobuf representation of that evaluator configuration. This protobuf represtatation is instantiated every time we evaluate a rule, so setting its attribute doesn't affect any other rules that might be using the same rule_type.
(Hopefully this answers the question)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I figured there was some aliasing going on, but I played dumb because I suspected the using of aliases was accidental.

pie.Endpoint = os.Getenv("MEDIATOR_UNSTABLE_PACKAGE_INTELLIGENCE_ENDPOINT")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think an env var is okay for now, but it would be nice eventually to have a set of options in Config from internal/config rather than reading from the environment here. But we can defer that refactor for now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea is actually to move this to be a provider. But yeah, it'll be refactored.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the config was what this PR started with but we had a call today with @JAORMX and decided against it in favour of addressing some of the technical debt in the evaluators first which will allow us to use just provider config instead.

}
return package_intelligence.NewPackageIntelligenceEvaluator(pie, cli)
default:
return nil, fmt.Errorf("unsupported rule type engine: %s", rt.Def.Eval.Type)
}
Expand Down