Developing Locally
The following technologies are required to build Airbyte locally.
​
Java 14​Node 14Python 3.7DockerPostgresqlJqCMake
Manually switching between different language versions can get hairy. We recommend using a version manager such as pyenv or jenv.
To start contributing:
Start by forking the repository
Clone the fork on your workstation:
git clone [email protected]:{YOUR_USERNAME}/airbyte.gitcd airbyteYou're ready to start!
To compile and build just the platform (not all the connectors):
SUB_BUILD=PLATFORM ./gradlew build
This will build all the code and run all the unit tests.
SUB_BUILD=PLATFORM ./gradlew build creates all the necessary artifacts (Webapp, Jars and Docker images) so that you can run Airbyte locally. Since this builds everything, it can take some time.
Gradle will use all CPU cores by default. If Gradle uses too much/too little CPU, tuning the number of CPU cores it uses to better suit a dev's need can help.
Adjust this by either, 1. Setting an env var: export GRADLE_OPTS="-Dorg.gradle.workers.max=3". 2. Setting a cli option: SUB_BUILD=PLATFORM ./gradlew build --max-workers 3 3. Setting the org.gradle.workers.max property in the gradle.properties file.
A good rule of thumb is to set this to (# of cores - 1).
On Mac, if you run into an error while compiling openssl (this happens when running pip install), you may need to explicitly add these flags to your bash profile so that the C compiler can find the appropriate libraries.
export LDFLAGS="-L/usr/local/opt/openssl/lib"export CPPFLAGS="-I/usr/local/opt/openssl/include"
SUB_BUILD=PLATFORM ./gradlew buildVERSION=dev docker-compose up
The build will take a few minutes. Once it completes, Airbyte compiled at current git revision will be running in dev mode in your environment.
In dev mode, all data will be persisted in /tmp/dev_root.
To run acceptance (end-to-end) tests, you must have the Airbyte running locally.
SUB_BUILD=PLATFORM ./gradlew buildVERSION=dev docker-compose upSUB_BUILD=PLATFORM ./gradlew :airbyte-tests:acceptanceTests
To format code in the repo, simply run ./gradlew format at the base of the repo.
Note: If you are contributing a Python file without imports or function definitions, place the following comment at the top of your file:
"""[FILENAME] includes [INSERT DESCRIPTION OF CONTENTS HERE]"""
Spin up Airbyte locally so the UI can make requests against the local API.
Stop the
webapp.
docker-compose stop webapp
Start up the react app.
cd airbyte-webappnpm installnpm start
Happy Hacking!
The Configuration API caches connector specifications. This is done to avoid needing to run docker everytime one is needed in the UI. Without this caching, the UI crawls. If you update the specification of a connector and you need to clear this cache so the API / UI pick up the change. You have two options: 1. Go to the Admin page in the UI and update the version of the connector. Updating to the same version will for the cache to clear for that connector. 1. Restart the server
VERSION=dev docker-compose down -vVERSION=dev docker-compose up
Sometimes you'll want to reset the data in your local environment. One common case for this is if you are updating an connector's entry in the database (airbyte-config/init/src/main/resources/config), often the easiest thing to do, is wipe the local database and start it from scratch. To reset your data back to a clean install of Airbyte, follow these steps:
Delete the datastore volumes in docker
VERSION=dev docker-compose down -vRemove the data on disk
rm -rf /tmp/dev_rootrm -rf /tmp/airbyte_localRebuild the project
SUB_BUILD=PLATFORM ./gradlew buildVERSION=dev docker-compose up -V
Somehow gradle didn't pick up the right java version for some reason. Find the install version and set the JAVA_HOME environment to point to the JDK folder.
For example:
env JAVA_HOME=/usr/lib/jvm/java-14-openjdk ./gradlew :airbyte-integrations:connectors:your-connector-dir:build