-
Notifications
You must be signed in to change notification settings - Fork 332
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 post-{commit,merge} #857
Conversation
Codecov Report
@@ Coverage Diff @@
## master #857 +/- ##
==========================================
+ Coverage 45.05% 45.09% +0.03%
==========================================
Files 140 140
Lines 10842 10853 +11
==========================================
+ Hits 4885 4894 +9
- Misses 5325 5326 +1
- Partials 632 633 +1
Continue to review full report at Codecov.
|
catalog/cataloger_merge_test.go
Outdated
{Path: newFilename}, | ||
{Path: overFilename, Seed: "seed1"}, | ||
{Path: delFilename, Deleted: true}, | ||
func validateMergeWithHooks( |
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.
a bit too much, no? a simple test of any simple merge use case should verify that hooks works - looking for an issue on a failed test that is written like that will make it hard on the developer.
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.
Isn't this the simple merge case? It requires creating 2 branches, creating an entry on one, merging, and then verifying that the hook was called (first case) and also that the hook can fail merging.
Rewriting as a separate pair of tests. It keeps this test shorter, but means much more test code to understand. Worst case you can ask for the old code back.
catalog/cataloger_commit_test.go
Outdated
c := testCataloger(t) | ||
|
||
t.Run("commit hooks run and see commit", func(t *testing.T) { | ||
repository := testCatalogerRepo(t, ctx, c, "repository", "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.
you can take out of the repo creation out of both tests
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.
Every other test does that too. We can refactor in a separate PR.
catalog/cataloger.go
Outdated
@@ -152,6 +152,10 @@ type Merger interface { | |||
Merge(ctx context.Context, repository, leftBranch, rightBranch, committer, message string, metadata Metadata) (*MergeResult, error) | |||
} | |||
|
|||
type Hookser interface { | |||
GetHooks() *CatalogerHooks |
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.
GetHooks() *CatalogerHooks | |
Hooks() *CatalogerHooks |
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.
Done!
// called in a current transaction context; if they return an error the transaction is rolled | ||
// back. Because these transactions are current, the hook can see the effect the operation only | ||
// on the passed transaction. | ||
type CatalogerHooks struct { |
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.
Maybe add a branch filter by name/regex?
o.w. you're relying on the hook itself to filter by it.
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.
Shall not do this. If needed in >1 hooks, we could add a wrapper ("decorator") function that filters a hook implementation for regexp. The added complexity of doing it here would include special semantics for merges -- there are two branches here.
Finally, I'm not sure it will be useful. For exports it's not, because it is hard to precompute the regexp (changes transactionally with the DB) and easy to check directly on the DB.
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.
Thanks!
I think I covered everything. Let me know if you would like me to roll back the new post-merge hook tests, I don't particularly like them either way (old or new).
catalog/cataloger.go
Outdated
@@ -152,6 +152,10 @@ type Merger interface { | |||
Merge(ctx context.Context, repository, leftBranch, rightBranch, committer, message string, metadata Metadata) (*MergeResult, error) | |||
} | |||
|
|||
type Hookser interface { | |||
GetHooks() *CatalogerHooks |
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.
Done!
// called in a current transaction context; if they return an error the transaction is rolled | ||
// back. Because these transactions are current, the hook can see the effect the operation only | ||
// on the passed transaction. | ||
type CatalogerHooks struct { |
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.
Shall not do this. If needed in >1 hooks, we could add a wrapper ("decorator") function that filters a hook implementation for regexp. The added complexity of doing it here would include special semantics for merges -- there are two branches here.
Finally, I'm not sure it will be useful. For exports it's not, because it is hard to precompute the regexp (changes transactionally with the DB) and easy to check directly on the DB.
catalog/cataloger_commit_test.go
Outdated
c := testCataloger(t) | ||
|
||
t.Run("commit hooks run and see commit", func(t *testing.T) { | ||
repository := testCatalogerRepo(t, ctx, c, "repository", "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.
Every other test does that too. We can refactor in a separate PR.
catalog/cataloger_merge_test.go
Outdated
{Path: newFilename}, | ||
{Path: overFilename, Seed: "seed1"}, | ||
{Path: delFilename, Deleted: true}, | ||
func validateMergeWithHooks( |
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.
Isn't this the simple merge case? It requires creating 2 branches, creating an entry on one, merging, and then verifying that the hook was called (first case) and also that the hook can fail merging.
Rewriting as a separate pair of tests. It keeps this test shorter, but means much more test code to understand. Worst case you can ask for the old code back.
Part of #534 but will be useful elsewhere. Allows loosely-coupled components, will be used to support export.
Co-authored-by: Barak Amar <barak.amar@treeverse.io>
Also explicitly take a test name in `testCreateEntryCalcChecksum` rather than manually appending it to a seed.
a7b1f31
to
1d173cb
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.
just suggested an alternative code for the tests, all the rest is cool.
@@ -83,9 +85,9 @@ func testCatalogerGetEntry(t testing.TB, ctx context.Context, c Cataloger, repos | |||
} | |||
} | |||
|
|||
func testCreateEntryCalcChecksum(key string, seed string) string { | |||
func testCreateEntryCalcChecksum(key string, testName string, seed string) string { |
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.
the plan was to pass the test name as seed if needed and call this function.
possibly calling this function again for verification.
there is no need to contact the test name when we have seed.
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.
The problem is that if any 2 tests use the same key and seed then they clash. It caused an actual problem when I copied calls around.
@@ -1200,3 +1201,60 @@ func TestCataloger_MergeFromChildAfterMergeFromParent(t *testing.T) { | |||
t.Fatalf("Merge err=%s, expected none", err) | |||
} | |||
} | |||
|
|||
func TestCataloger_Merge_Hooks(t *testing.T) { |
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.
let me know what you think about the diff test code - if you think it is easier to read, update this one - max I can live with both cases or give you the code for this one.
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.
Will copy that code over here, you're correct that it's a bit nicer.
Co-authored-by: Barak Amar <barak.amar@treeverse.io>
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.
Thanks!
Pulling once tests pass.
@@ -1200,3 +1201,60 @@ func TestCataloger_MergeFromChildAfterMergeFromParent(t *testing.T) { | |||
t.Fatalf("Merge err=%s, expected none", err) | |||
} | |||
} | |||
|
|||
func TestCataloger_Merge_Hooks(t *testing.T) { |
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.
Will copy that code over here, you're correct that it's a bit nicer.
@@ -83,9 +85,9 @@ func testCatalogerGetEntry(t testing.TB, ctx context.Context, c Cataloger, repos | |||
} | |||
} | |||
|
|||
func testCreateEntryCalcChecksum(key string, seed string) string { | |||
func testCreateEntryCalcChecksum(key string, testName string, seed string) string { |
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.
The problem is that if any 2 tests use the same key and seed then they clash. It caused an actual problem when I copied calls around.
Part of #534 but will be useful elsewhere. Allows loosely-coupled components, will be used to
support export.