-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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.
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
airbyte-ci: ignore CAT results when running on community connectors #39361
airbyte-ci: ignore CAT results when running on community connectors #39361
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Ignored Deployment
|
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @alafanechere and the rest of your teammates on Graphite |
557a7c3
to
1db035d
Compare
1db035d
to
bc78187
Compare
bc78187
to
6a006a5
Compare
f3eadca
to
3d1653c
Compare
6a006a5
to
51799c8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I understand what's going on now! To approve this, I'd like one more engineer to take a look.
My ask is about variable naming clarity. It feels to me that the intent behind consider_result_in_overall_status
is basically is_hard_failure
.
- I.e. if it's a hard fail (consider in overall result == true), fail the pipeline if this is failed.
- If it's not a hard fail, than only fail the pipeline if the corresponding check on master does not fail.
If my understanding of the logic is correct, what would be a good name for this? perhaps it should be soft_result
or fail_contingent_on_master
?
@@ -326,13 +326,18 @@ async def get_step_result(self, container: Container) -> StepResult: | |||
content=container.file(self.REPORT_LOG_PATH), | |||
to_upload=True, | |||
) | |||
# When the current connector is not certified we want to report the acceptance test results but not consider them in the overall status of the test pipeline | |||
consider_result_in_overall_status = ( | |||
self.context.connector.metadata.get("supportLevel") == "certified" or self.context.ci_context == CIContext.MASTER |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bnchrch this might change if we go for a different gate
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we pull this out into a helper method so it's easier to find?
@@ -60,6 +60,10 @@ def json_report_remote_storage_key(self) -> str: | |||
def failed_steps(self) -> List[StepResult]: | |||
return [step_result for step_result in self.steps_results if step_result.status is StepStatus.FAILURE] | |||
|
|||
@property | |||
def considered_failed_steps(self) -> List[StepResult]: | |||
return [step_result for step_result in self.failed_steps if step_result.consider_in_overall_status] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't this just return either full list of all failed steps, or none at all? consider_in_overall_status
is just a bool that stays the same for all steps, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a StepResult
property with a default value of True
, for which we've only overridden it for the AcceptanceTests
StepResult
. So it should still see considered failed unit tests or qa checks, for example
@@ -326,13 +326,18 @@ async def get_step_result(self, container: Container) -> StepResult: | |||
content=container.file(self.REPORT_LOG_PATH), | |||
to_upload=True, | |||
) | |||
# When the current connector is not certified we want to report the acceptance test results but not consider them in the overall status of the test pipeline | |||
consider_result_in_overall_status = ( | |||
self.context.connector.metadata.get("supportLevel") == "certified" or self.context.ci_context == CIContext.MASTER |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we pull this out into a helper method so it's easier to find?
@@ -60,6 +60,10 @@ def json_report_remote_storage_key(self) -> str: | |||
def failed_steps(self) -> List[StepResult]: | |||
return [step_result for step_result in self.steps_results if step_result.status is StepStatus.FAILURE] | |||
|
|||
@property | |||
def considered_failed_steps(self) -> List[StepResult]: | |||
return [step_result for step_result in self.failed_steps if step_result.consider_in_overall_status] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a StepResult
property with a default value of True
, for which we've only overridden it for the AcceptanceTests
StepResult
. So it should still see considered failed unit tests or qa checks, for example
@@ -162,7 +162,11 @@ function copyToClipBoard(htmlElement) { | |||
{% if step_result.status == StepStatus.SUCCESS %} | |||
<label for="{{ step_result.step.title }}" class="lbl-toggle success">{{ step_result.step.title }} | {{ format_duration(step_result.step.run_duration) }}</label> | |||
{% elif step_result.status == StepStatus.FAILURE %} | |||
{% if not step_result.consider_in_overall_status %} | |||
<label for="{{ step_result.step.title }}" class="lbl-toggle failure">{{ step_result.step.title }} | Ignored | {{ format_duration(step_result.step.run_duration) }}</label> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<label for="{{ step_result.step.title }}" class="lbl-toggle failure">{{ step_result.step.title }} | Ignored | {{ format_duration(step_result.step.run_duration) }}</label> | |
<label for="{{ step_result.step.title }}" class="lbl-toggle failure">{{ step_result.step.title }} | Ignored (Failed) | {{ format_duration(step_result.step.run_duration) }}</label> |
or something to indicate that we won't ignore it if it succeeds (and point out that it did fail although it was ignored), would be helpful, I think
@@ -70,7 +74,7 @@ def skipped_steps(self) -> List[StepResult]: | |||
|
|||
@property | |||
def success(self) -> bool: | |||
return len(self.failed_steps) == 0 and (len(self.skipped_steps) > 0 or len(self.successful_steps) > 0) | |||
return len(self.considered_failed_steps) == 0 and (len(self.skipped_steps) > 0 or len(self.successful_steps) > 0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Edge case: if we only return failed and ignored steps, this doesn't return true (because no steps were successfull/skipped). don't think we need to worry about this too much, but we're definitely getting out of our enum groups and into more complicated stuff
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My ask is about variable naming clarity. It feels to me that the intent behind consider_result_in_overall_status is basically is_hard_failure.
I.e. if it's a hard fail (consider in overall result == true), fail the pipeline if this is failed.
If it's not a hard fail, than only fail the pipeline if the corresponding check on master does not fail.
This is interesting - we could even pull this back into our enums, instead of creating a second option, by creating
StepStatus.SOFT_FAILURE
and StepStatus.HARD_FAILURE
for example
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this new enum strategy but it'd would require a significant refacto to change the failure detection everywhere it's used. I suggest doing it if we have multiple "soft failure" implementation coming up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Edge case: if we only return failed and ignored steps, this doesn't return true (because no steps were successfull/skipped). don't think we need to worry about this too much, but we're definitely getting out of our enum groups and into more complicated stuff
I remember that I originally set this to return not self.failed_steps
(which we could transform to return not self.considered_failed_steps
) . I remember I added the and
to fix another edge case - I should have added a comment to remember which one!
ff30368
to
8d9929b
Compare
Merge activity
|
8d9929b
to
c9c37bb
Compare
What
We decided that it was fine to make CI pass on community connectors if their acceptance tests results are not made worse than what they are on
master
.Detection of "not made worse" is implemented in #39363
To do so we have to change the CI logic slightly to allow CAT to fail on community connector while still emitting a 🟢 CI status.
It'll allow keeping the original CAT results for debugging but not fail CI if they are not passing.
How
Introduce a
consider_result_in_overall_status
flag at theStepResult
level.It allows
Step
to emitStepResult
which won't be considered in the overall computation of success / failure for a pipeline.Update the HTML report to show when a step was ignored from overall results.
Change the definition of
success
at theReport
level to integrate this newconsider_result_in_overall_status
flag.