ingestor: Return fallback body on certain HTTP status types #1172
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
At the moment, all HTTP errors from the ingestor are treated as errors and returned to the caller. This also means that neither the evaluator nor the remediate calls are called. Some endpoints, like branch protection, do not exist if branch protection is not enabled, which prevents us from going forward in the engine and actually remediating the issue. This is visible with the rule_type test command as: ``` $ go run cmd/dev/main.go rule --profile /Users/jakub/devel/playground/remediate.yaml --rule-type examples/github/rule-types/branch_protection.yaml --entity /Users/jakub/devel/playground/repository.yaml Profile valid according to the JSON schema! Error: error evaluating rule type: error ingesting data: cannot do request: cannot make request: GET https://api.github.com/repos/jakubtestorg/testrepo/branches/main/protection: 404 Branch not protected [] Error on execute: error evaluating rule type: error ingesting data: cannot do request: cannot make request: GET https://api.github.com/repos/jakubtestorg/testrepo/branches/main/protection: 404 Branch not protected [] exit status 1 ``` This patch defines a configurable per-rule fallback where for rules that need this functionality, a dummy body is returned, which just falls throught the evaluator and then eventually makes the remediate step work. I chose this programmable fallback approach over just falling back to an empty body to prevent us from hiding issues where we might expand a template wrong or just have a typo in the endpoint - this way we will only proceed on error codes if the rule type explicitly says so.
JAORMX
reviewed
Oct 11, 2023
JAORMX
approved these changes
Oct 11, 2023
|
Makes sense to me! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
At the moment, all HTTP errors from the ingestor are treated as errors
and returned to the caller. This also means that neither the evaluator
nor the remediate calls are called.
Some endpoints, like branch protection, do not exist if branch
protection is not enabled, which prevents us from going forward in the
engine and actually remediating the issue. This is visible with the
rule_type test command as:
This patch defines a configurable per-rule fallback where for rules that
need this functionality, a dummy body is returned, which just falls
throught the evaluator and then eventually makes the remediate step
work.
I chose this programmable fallback approach over just falling back to an
empty body to prevent us from hiding issues where we might expand a
template wrong or just have a typo in the endpoint - this way we will
only proceed on error codes if the rule type explicitly says so.