FYI @s Just wanted to let you know but I noticed with the Snowflake destination, sometimes it creates tables with a different naming than what a user would expect and i didn't quite understand why yet... For example, I created a source with the file connector specifying the stream's name to be

airports

but i end up with tables called

airport_1604942713720

instead (which breaks normalization afterward since it's relying on finding

airports

.... I hope the work on the naming would kind of solve these kinds of issues!

[ITT] @s asked me what I thought about using the generator for a new integration:

Is master supposed to pass?

Hello this PR should fix the

oneOf

issue we had in the UI with the Source File: https://github.com/airbytehq/airbyte/pull/872 I also added along some extra options for JSON loading (experimental at this point) for manual testing of nested JSON Schemas

how am i suppose to interpret the output of the link checker?

docs/integrations/destinations/local-csv/README.md

this isn’t an actual file in source.

Status: Downloaded newer image for airbyte/tool-link-checker:latest
- (2183:63151) 'CSV Dest..' => <https://github.com/airbytehq/airbyte/tree/594c90e3bf6cba4d39dfdf69131567cf6d0da3da/docs/integrations/destinations/local-csv/README.md> (HTTP 404)
Found broken links

yes

@charles I'm running into some problems with google adwords -> postgres

Anyone have an objection to turning on

Automatically delete head branches

so we don't end up with a bunch of merged branches in https://github.com/airbytehq/airbyte/branches/all

dumb gradle question. when do i use just the

project(...)

syntax versus when i do the

files(project(…))

syntax? is the idea that i’m specifying that i only depend on some specific task of the project that i’m depending on?

integrationTestImplementation project(':airbyte-integrations:connectors:destination-snowflake')
    integrationTestImplementation files(project(':airbyte-integrations:bases:base-normalization').airbyteDocker.outputs)

Has anyone run into this problem? When execute command

./gradlew clean

, I get this error:

An exception occurred applying plugin request [id: 'airbyte-docker']
> Failed to apply plugin [id 'airbyte-docker']
   > A problem occurred starting process 'command 'docker''

is there a reason we don’t currently do catalog discovery before running a sync, or is it just something we didn’t fully scope and so left it for later implementation?

Is there a reason

DefaultSyncWorker

allows a generic

T

instead of always using

AirbyteMessage

?

For jsonschema do we prefer snake case or camel case?

Why are we passing state messages to the destination at all? Should they being doing anything with them?

does anyone else get these errors when they clean build? it's like a dependency isn't getting respected or something. curious if i'm the only one.

> Task :airbyte-integrations:connectors:source-facebook-marketing-api-singer:unitTest FAILED
[python] .venv/bin/python -m pytest unit_tests
         ============================= test session starts ==============================
         platform darwin -- Python 3.7.8, pytest-6.1.2, py-1.9.0, pluggy-0.13.1
         rootdir: /Users/charles/code/airbyte/airbyte-integrations/connectors/source-facebook-marketing-api-singer
         collected 0 items / 1 error

         ==================================== ERRORS ====================================
         ___________________ ERROR collecting unit_tests/unit_test.py ___________________
         ImportError while importing test module '/Users/charles/code/airbyte/airbyte-integrations/connectors/source-facebook-marketing-api-singer/unit_tests/unit_test.py'.
         Hint: make sure your test modules/packages have valid Python names.
         Traceback:
         .venv/lib/python3.7/importlib/__init__.py:127: in import_module
             return _bootstrap._gcd_import(name[level:], package, level)
         unit_tests/unit_test.py:25: in <module>
             from base_python import AirbyteLogger
         base_python/__init__.py:25: in <module>
             from .integration import AirbyteSpec, ConfigContainer, Destination, Integration, Source
         base_python/integration.py:30: in <module>
             from airbyte_protocol import AirbyteCatalog, AirbyteConnectionStatus, AirbyteMessage, ConnectorSpecification
         airbyte_protocol/__init__.py:25: in <module>
             from .models import (
         airbyte_protocol/models/__init__.py:2: in <module>
             from .airbyte_protocol import *
         E   ModuleNotFoundError: No module named 'airbyte_protocol.models.airbyte_protocol'
         =========================== short test summary info ============================
         ERROR unit_tests/unit_test.py
         !!!!!!!!!!!!!!!!!!!! Interrupted: 1 error during collection !!!!!!!!!!!!!!!!!!!!
         =============================== 1 error in 0.51s ===============================

build update: we're still getting build failures on master for mssql/mysql tests.

Can someone review this PR please? https://github.com/airbytehq/airbyte/pull/1038 I also fixed some tests failure in the acceptance tests related to the schema name changes... however the build doesn't pass on the CI for some reasons with docker images that i don't understand Thanks

@charles can you remind me why the cursor field is an array in the catalog? is it for supporting nested cursors, or for supporting more than one cursor?

Github Actions is basically down :/

Anyone have a good template or article on how to do good release messages in github. We've been a bit ad hoc about this and I think it would be nice if we had a basic template.

The Local CSV destination has an unexpected behavior

do we currently have any way of specifying that a destination cannot accept incremental syncs? is it enforced?

We have a problem with our docs. Working with gitbook to fix it. Their certificate for docs.airbyte.io stopped working so docs were not accessible anymore. I removed the custom domain

random thought. how hard would it be to set up a CI job in github that handles bumping the version of a connector that is triggered in the same way that we manually trigger integration tests with comments @Jared Rhizor (Airbyte)? it's kinda of a hassle right now to do it locally (especially since we all have residential and not business upload speeds for docker layers).

Any insights..

Question : Why Airbyte choose the approach to do the sync as json structure instead of full schema as it is sync to target DB similar to fivetran , stitch?

Where can I see the detailed error when setting up the connector? I am trying to work with Google Analytics and not sure why it's not getting connected. All connection tests are failing.

could use a review on this PR to add incremental to postgres source when someone has a chance. there are some open questions so i'd like a second opinion: https://github.com/airbytehq/airbyte/pull/1172

question : is there any way else to run other than docker compose and see all the logs?

should

release_version

still be doing

./gradlew clean build

? or would it make sense to transition it to:

./gradlew clean
./gradlew composeBuild