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

Source Faker: Add support for PyPi and AirbyteLib entrypoints #34033

Merged
merged 8 commits into from
Jan 11, 2024

Conversation

aaronsteers
Copy link
Collaborator

@aaronsteers aaronsteers commented Jan 8, 2024

This adds compatibility with AirbyteLib.

Includes PyPi declaration as defined in:

This PR replaces the related changes in:

This PR also includes a generic Python DevContainer, which can be used for testing in Codespaces. I'm happy to remove it though and move to a different PR if anyone has an objection. I confirmed I was able to run pytest from this decontainer, and that all tests are passing.

Copy link

vercel bot commented Jan 8, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment
Name Status Preview Comments Updated (UTC)
airbyte-docs ⬜️ Ignored (Inspect) Visit Preview Jan 9, 2024 0:16am

Copy link
Contributor

github-actions bot commented Jan 8, 2024

Before Merging a Connector Pull Request

Wow! What a great pull request you have here! 🎉

To merge this PR, ensure the following has been done/considered for each connector added or updated:

  • PR name follows PR naming conventions
  • Breaking changes are considered. If a Breaking Change is being introduced, ensure an Airbyte engineer has created a Breaking Change Plan.
  • Connector version has been incremented in the Dockerfile and metadata.yaml according to our Semantic Versioning for Connectors guidelines
  • You've updated the connector's metadata.yaml file any other relevant changes, including a breakingChanges entry for major version bumps. See metadata.yaml docs
  • Secrets in the connector's spec are annotated with airbyte_secret
  • All documentation files are up to date. (README.md, bootstrap.md, docs.md, etc...)
  • Changelog updated in docs/integrations/<source or destination>/<name>.md with an entry for the new version. See changelog example
  • Migration guide updated in docs/integrations/<source or destination>/<name>-migrations.md with an entry for the new version, if the version is a breaking change. See migration guide example
  • If set, you've ensured the icon is present in the platform-internal repo. (Docs)

If the checklist is complete, but the CI check is failing,

  1. Check for hidden checklists in your PR description

  2. Toggle the github label checklist-action-run on/off to re-run the checklist CI.

@aaronsteers aaronsteers marked this pull request as ready for review January 8, 2024 23:24
@aaronsteers aaronsteers changed the base branch from aj/generic-python-devcontainer to master January 8, 2024 23:48
@aaronsteers aaronsteers changed the title Faker Source: Add support for standard AirbyteLib entrypoints Faker Source: Add support for PyPi and AirbyteLib entrypoints Jan 8, 2024
@aaronsteers aaronsteers changed the title Faker Source: Add support for PyPi and AirbyteLib entrypoints Source Faker: Add support for PyPi and AirbyteLib entrypoints Jan 8, 2024
@@ -1,6 +1,6 @@
// For format details, see https://aka.ms/devcontainer.json. For config options, see the
{
"name": "Connector Development DevContainer (Generic)",
"name": "Java Development DevContainer (Generic)",
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Updated the name to distinguish the generic Java devcontainer from the Python one.

Copy link
Contributor

@alafanechere alafanechere left a comment

Choose a reason for hiding this comment

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

The source-faker changes LGTM.
I raised a couple of concerns / suggestion about the devcontainer configuration.
I'm not using devcontainer myself so my suggestion might be unrealistic / not matching what you like to achieve.

Please engage in a more in-depth discussion if you'd like to broaden the adoption of devcontainer.json among our connector developers. My main concern is to find a way to guarantee a certain level of consistency between the dev environment (managed by devcontainers.json) and the build environment (managed by airbyte-ci) so that developer do not face late CI failures / bad surprises on release.

Copy link
Contributor

Choose a reason for hiding this comment

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

Can we use python connector base image as a development container for connectors?

The problem we might have is that:

  • Python connectors base image is based on Python 3.9.18
  • airbyte-ci (dagger) requires Python 3.10

So it's kinda hard to have a unified dev container which can match connector runtime with airbyte-ci installed.

We should ideally have a devcontainer with multiple python version installed, 3.9 for connectors, 3.10 for airbyte-ci.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@alafanechere - I tested successfully and was able to run airbyte-ci without issue, thanks to the make option.

Happy to keep iterating on this. For now, it gives a baseline experience that's much better than starting with a blank of generic container.

"initializeCommand": "git config --add safe.directory /workspaces/airbyte",

// Setup airbyte-ci on the container:
"postCreateCommand": "make tools.airbyte-ci-dev.install",
Copy link
Contributor

@alafanechere alafanechere Jan 9, 2024

Choose a reason for hiding this comment

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

Is airbyte-ci correctly working inside the container?
If it does I think it's thanks to the docker-in-docker feature.
The problem with this approach is that the dagger engine in use will be using your devcontainer docker / buildkit engine, and not your host one.

This can impact performance and caching.

To not use docker-in-docker you can try to:

  • Mount the docker socket to the dev container so that it can interact with your host docker engine
  • Set the _EXPERIMENTAL_DAGGER_RUNNER_HOST env var to tell the dagger engine to use this mounted socket. (example in CI here)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It works fine as-is for now. In the cloud, I think docker-in-docker is correct, and probably the best we can get. There's also a 'docker-from-docker' option that might work better locally - but I don't have familiar with that as of yet, and so I'd like to keep as is for now.

Please engage in a more in-depth discussion if you'd like to broaden the adoption of devcontainer.json among our connector developers.

Agreed. No need to push this as of now. I think over time we will get to a good place where we have collective confidence that the containers give a solid and consistent experience.

Copy link
Contributor

@flash1293 flash1293 left a comment

Choose a reason for hiding this comment

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

Approving for faker changes, @alafanechere s comments on dev container make sense to me

@aaronsteers aaronsteers merged commit 7d7f33c into master Jan 11, 2024
30 checks passed
@aaronsteers aaronsteers deleted the aj/source-faker/airbytelib-entrypoints branch January 11, 2024 08:16
jatinyadav-cc pushed a commit to ollionorg/datapipes-airbyte that referenced this pull request Feb 26, 2024
jatinyadav-cc pushed a commit to ollionorg/datapipes-airbyte that referenced this pull request Feb 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/connectors Connector related issues area/documentation Improvements or additions to documentation connectors/source/faker
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants