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.

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

✨ Adding tests for catalog availability #436

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

LalatenduMohanty
Copy link
Member

@LalatenduMohanty LalatenduMohanty commented Oct 17, 2024

This is a follow-up from the previous PR #421 i.e. commit d320249

@LalatenduMohanty LalatenduMohanty requested a review from a team as a code owner October 17, 2024 14:57
@LalatenduMohanty LalatenduMohanty changed the title ✨ [WIP] Adding tests for catalog availability ✨ Adding tests for catalog availability Oct 18, 2024
@LalatenduMohanty LalatenduMohanty force-pushed the tests_for_availability branch 2 times, most recently from 927984c to fbc71e4 Compare October 21, 2024 15:51
Copy link

codecov bot commented Oct 21, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 37.83%. Comparing base (67d3a34) to head (fbc71e4).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #436   +/-   ##
=======================================
  Coverage   37.83%   37.83%           
=======================================
  Files          15       15           
  Lines        1208     1208           
=======================================
  Hits          457      457           
  Misses        701      701           
  Partials       50       50           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

{
Type: catalogdv1alpha1.TypeProgressing,
Status: metav1.ConditionFalse,
Reason: catalogdv1alpha1.ReasonDisabled,
Copy link
Member Author

Choose a reason for hiding this comment

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

I was expecting that the status would change but it is not changing which is weird.

Copy link
Collaborator

Choose a reason for hiding this comment

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

The first reconciliation after the Availability is changed back to Enabled is going to add the finalizers back here. The second reconciliation that'll happen AFTER the finalizer is added will be updating these conditions after finishing its job.

One way we can handle this is probably by breaking this test into two tests

  1. "ClusterCatalog previously disabled, is enabled back, finalizers are added back"
  2. "ClusterCatalog previously disabled, is enabled back, finalizers have been added back, status conditions updated to show Serving=True, Progressing=False (or whatever's appropriate)"

Copy link
Member Author

Choose a reason for hiding this comment

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

This is a good idea. let me try that. Thanks.

Copy link
Collaborator

@anik120 anik120 left a comment

Choose a reason for hiding this comment

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

Could you added a little bit of Description in the commit message for the PR too?(besides the main title). It'll help out someone who hasn't seen the previous PRs about Availability (so the words "catalog availability" doesn't mean much to them yet).

I like creating paper trails. Eg

"This is a follow up to PR #___, that added a new field Availability".

Hopefully the first PR had a link to the RFC, in which case the paper trail would be complete :)

@@ -736,6 +736,89 @@ func TestCatalogdControllerReconcile(t *testing.T) {
},
},
},
{
name: "catalog availability set to enable, status should get updated",
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we be more clear about what exactly we expect the status to look like? It doesn't have to be very detailed, but a little more clarity will be helpful.

For eg, this one says status updated to reflect terminal error state(Blocked) and error is returned, this one says should reflect in status that it's not progressing anymore, and is serving, etc.

{
Type: catalogdv1alpha1.TypeProgressing,
Status: metav1.ConditionFalse,
Reason: catalogdv1alpha1.ReasonDisabled,
Copy link
Collaborator

Choose a reason for hiding this comment

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

The first reconciliation after the Availability is changed back to Enabled is going to add the finalizers back here. The second reconciliation that'll happen AFTER the finalizer is added will be updating these conditions after finishing its job.

One way we can handle this is probably by breaking this test into two tests

  1. "ClusterCatalog previously disabled, is enabled back, finalizers are added back"
  2. "ClusterCatalog previously disabled, is enabled back, finalizers have been added back, status conditions updated to show Serving=True, Progressing=False (or whatever's appropriate)"

@LalatenduMohanty
Copy link
Member Author

Could you added a little bit of Description in the commit message for the PR too?(besides the main title). It'll help out someone who hasn't seen the previous PRs about Availability (so the words "catalog availability" doesn't mean much to them yet). I like creating paper trails. Eg "This is a follow up to PR #___, that added a new field Availability".

Yes, good call out. Will fix that.

Hopefully the first PR had a link to the RFC, in which case the paper trail would be complete :)

Not a fan of mentioning google docs in the PRs specially when they are not 100% public docs. RFC is only shared with upstream OLM groups but the code most likely would end up in places where folks wont be part of the OLM group.

This is a follow-up from the previous PR operator-framework#421 i.e. commit d320249

Signed-off-by: Lalatendu Mohanty <[email protected]>
@LalatenduMohanty
Copy link
Member Author

One test is panicking currently, so looking in to it https://github.com/operator-framework/catalogd/actions/runs/11524939322/job/32086163161?pr=436

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants