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

Add canary test for visibility archival #3059

Merged
merged 4 commits into from
Feb 24, 2020
Merged

Conversation

yycptt
Copy link
Contributor

@yycptt yycptt commented Feb 19, 2020

No description provided.

@coveralls
Copy link

coveralls commented Feb 19, 2020

Coverage Status

Coverage decreased (-0.2%) to 67.187% when pulling 2791555 on yycptt:vis-archival-canary into c09186f on uber:master.

listReq.NextPageToken = listResp.NextPageToken
}

if len(listResp.Executions) == 0 {
Copy link
Contributor

Choose a reason for hiding this comment

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

Roughly how many do we expect to have here? Seems like if we can assert something stronger than more than 0 it would be good.

Copy link
Contributor Author

@yycptt yycptt Feb 20, 2020

Choose a reason for hiding this comment

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

I put more thought on this last night and made the following two changes:

  1. Separate the canary test for history archival and visibility archival so they can be enabled or disabled independently.
  2. Created an interface for validating visibility archival (a template) which each visibility archival scheme should implement. It basically tells canary if the test should be run, what the query is and how the result should be validated. With this interface, I believe the code is general enough for all archiver implementations and each implementation can have more control over the test.

I made those changes because I think when open source customers use canary in production, it's unlikely they will set the scheme for canary domain to be filestore, it will be either s3 or gcp or some other implementation. So we should make the code more general and flexible.

What's your thought on this?

Copy link
Contributor

Choose a reason for hiding this comment

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

This makes a lot of sense :)

Copy link
Contributor

@andrewjdawson2016 andrewjdawson2016 left a comment

Choose a reason for hiding this comment

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

A few nits

@yycptt yycptt merged commit 287f8b5 into uber:master Feb 24, 2020
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.

3 participants