-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Bulk Load CDK: Add integration test using in-memory mock destination #45634
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Skipped Deployment
|
This stack of pull requests is managed by Graphite. Learn more about stacking. |
@Requires(env = ["test"]) | ||
//@Factory | ||
//@Replaces(factory = DestinationCatalogFactory::class) | ||
//@Requires(env = ["test"]) |
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.
@johnny-schmidt I did this yesterday as a quick hack just to get the test to run (otherwise micronaut threw a duplicate bean error). I think the easiest solution is to add another env to the Requires clause? @Requires(env=["test", "mock_catalog_factory"])
and then add that new env to all the tests that rely on this bean?
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 could also add some Requires thing to the MockDestinationWrite, but then I'd need to plumb it down to the CliRunner
(... I could also move this stuff to testIntegration
and wire up a proper integration test task 🤷 no strong opinion. But I do think it would be nice for the MockCatalogFactory to be an explicit opt-in)
@@ -0,0 +1,4 @@ | |||
--- | |||
data: | |||
dockerRepository: "airbyte/fake-source" |
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'll update this file, it's needed to make something in the connector runner happy
66dc128
to
9708552
Compare
2e326f0
to
f377e2a
Compare
9708552
to
23585e5
Compare
f377e2a
to
5fd6001
Compare
23585e5
to
ea8314f
Compare
5fd6001
to
371f6c7
Compare
ea8314f
to
7c7d04d
Compare
371f6c7
to
f576bce
Compare
7c7d04d
to
d4b2c4e
Compare
f576bce
to
40e7de2
Compare
d4b2c4e
to
f20b33d
Compare
40e7de2
to
3b39969
Compare
f20b33d
to
9511fda
Compare
5da57c2
to
9d49f7d
Compare
9511fda
to
391756a
Compare
9d49f7d
to
7c5df8d
Compare
cfb0cc1
to
91e6e18
Compare
e3a99c2
to
9e8312a
Compare
3c6895c
to
096dc33
Compare
9e8312a
to
9797a8a
Compare
.../load/src/testFixtures/kotlin/io/airbyte/cdk/test/write/BasicFunctionalityIntegrationTest.kt
Show resolved
Hide resolved
|
||
sourceSets { | ||
integrationTest { | ||
} |
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.
Do these require paths?
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 guess it defaults?
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.
Is the point to support this: Add a new integrationTest task+classpath, to avoid accidentally breaking any micronaut stuff in unit tests. Also updates our github actions (I think?) to call that task as needed.
Like the point is to prevent connector integration tests from pulling this in? Maybe a clearer/pattern-following name like test-integration-cdk
?
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.
welp, my comment on this got hidden #45634 (comment) (tl;dr yes, it populates the paths by default. I should probably just make that an in-code comment 🤔 )
it's more that I'm declaring Singletons without @Requires
(b/c I didn't want to add more plumbing into CliRunner/AirbyteConnectorRunner). So putting this stuff into a separate task+classpath (instead of just test
) hopefully avoids annoying duplicate bean errors in the cdk unit tests. (connector integration tests wouldn't be affected either way, since they only depend on testFixtures)
so I think integrationTest is the right name? (but also, I don't really feel strongly :P )
- test -> cdk unit tests
- testFixtures -> cdk tooling for connector tests
- integrationTest -> cdk integration tests
...ad/src/integrationTest/kotlin/io/airbyte/cdk/mock_integration_test/MockDestinationBackend.kt
Outdated
Show resolved
Hide resolved
.../integrationTest/kotlin/io/airbyte/cdk/mock_integration_test/MockDestinationConfiguration.kt
Show resolved
Hide resolved
...oad/src/integrationTest/kotlin/io/airbyte/cdk/mock_integration_test/MockDestinationWriter.kt
Show resolved
Hide resolved
.../integrationTest/kotlin/io/airbyte/cdk/mock_integration_test/MockDestinationConfiguration.kt
Show resolved
Hide resolved
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 mock destination looks great, I like how the test world is shaping up.
I'm not sure about the gradle stuff. Makes sense to run it with the bulk publish but maybe not with the check, in case I'm missing something. All the other ITs explicitly run after check.
Also definitely get eyes on it from sources.
9797a8a
to
8635353
Compare
e5ddcf7
to
b8aa176
Compare
talked with @rodireich offline a few days ago and we feel ok with this - @johnny-schmidt can you take another look + approve? (the diff since your last review is just https://github.com/airbytehq/airbyte/pull/45634/files/a718581aaf73fd9d8d5730cdd11988c19a1af413..1454562e7efec83333849e43c539de815e3f7827, i.e. incorporating your idea about ConcurrentHashMap, having |
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.
LGTM!
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.
Sorry for the late review. I only looked at the gradle stuff. I'm just confused by the task dependencies because the intent behind them is not clear to me, other than that everything seems fine.
edit: the mustRunAfter check
really tripped me up, but it's fine
@@ -61,6 +61,12 @@ allprojects { | |||
} | |||
} | |||
|
|||
tasks.register('bulkCdkIntegrationTest').configure { | |||
// findByName returns the task, or null if no such task exists. | |||
// we need this because not all submodules have an integrationTest task. |
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.
FYI, alternatively, tasks.matching
is also useful for this purpose, perhaps even preferred
CI: true | ||
with: | ||
job-id: bulk-cdk-publish | ||
concurrent: true |
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.
there are some read-only flags that you can set here, not sure if they're actually helpful
in any case none of this seems wrong
testClassesDirs = sourceSets.integrationTest.output.classesDirs | ||
classpath = sourceSets.integrationTest.runtimeClasspath | ||
useJUnitPlatform() | ||
mustRunAfter tasks.check |
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.
what's this for? why not have this run as part of check
? is this because of the dependency on assemble
for the docker image? if it's the latter, it's better to declare that dependency explicitly with dependsOn assemble
. These mustRunAfter
constraints are typically not what you really want for these kinds of tasks.
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.
this really tripped me up; did you in fact mean to have check
depend on integrationTest
? if so please let me know @edgao
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.
iirc I copypasted this from stackoverflow without reading it :P I did in fact want to have check depend on integrationTest
(which I think is what I did later on, with the rootProject.check.dependsOn
thing? This mustRunAfter thing probably isn't really needed - probably the assumption on SO was that integrationTest is slow, and therefore only worth running if check
succeeded. Which isn't true here.)
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!
FYI chatgpt is great at generating gradle scripts
Add "integration tests" for the CDK, which test full syncs/etc. against an in-memory destination. Very rudimentary for now. Add a new integrationTest task+classpath, to avoid accidentally breaking any micronaut stuff in unit tests. Also updates our github actions (I think?) to call that task as needed.
also - OutputRecord.airbyteMeta is now a proper struct instead of JsonNode; updated RecordDifferTest appropriately. (IntNode / LongNode equality is annoying, in that
IntNode(42) != LongNode(42)
).closes https://github.com/airbytehq/airbyte-internal-issues/issues/9960