1
0
mirror of synced 2026-01-03 15:04:01 -05:00
Files
airbyte/docs/contributing-to-airbyte/developing-on-docker.md
Parker Mossman 884a94ed29 Un-Revert OSS branch build for Cloud workflow (#11808)
* Revert "Revert "Build OSS branch for deploying to Cloud env (#11474)""

This reverts commit 55e3c1e051.

* add action to get dev branch tag to OSS project instead of doing it in cloud

* remove dev branch version action, going to do this in cloud afterall
2022-04-08 15:17:04 -07:00

76 lines
3.5 KiB
Markdown

# Developing on docker
## Incrementality
The docker build is fully incremental for the platform build, which means that it will only build an image if it is needed. We need to keep it that
way.
A task generator, `getDockerBuildTask`, is available for building a docker image for any given module. Behind the scene, it will generate a
task which will run the build of a docker image in a specific folder. The goal is to make sure that we have an isolated
context which helps with incrementality. All files that need to be present in the docker image will need to be copy into this folder. The generate
method takes 2 arguments:
- The image name, for example if `foo` is given as an image name, the image `airbyte/foo` will be created
- The project directory folder. It is needed because the `getDockerBuildTask` is declared in the rootProject
## Adding a new docker build
Once you have a `Dockerfile`, generating the docker image is done in the following way:
- specify the artifact name, the project directory, the version, and the tag.
- make sure that the Dockerfile is properly copied to the docker context dir before building the image
- make the build docker task to depend on the `assemble` task.
For example:
```groovy
Task dockerBuildTask = getDockerBuildTask("cli", project.projectDir, rootProject.ext.version, rootProject.ext.image_tag)
dockerBuildTask.dependsOn(copyDocker)
assemble.dependsOn(dockerBuildTask)
```
If you need to add files in your image you need to copy them in `build/docker/bin` first. The need to happen after the `copyDocker` task.
The `copyDocker` task clean up the `build/docker` folder as a first step.
For example:
```groovy
task copyScripts(type: Copy) {
dependsOn copyDocker
from('scripts')
into 'build/docker/bin/scripts'
}
Task dockerBuildTask = getDockerBuildTask("init", project.projectDir, rootProject.ext.version, rootProject.ext.image_tag)
dockerBuildTask.dependsOn(copyScripts)
assemble.dependsOn(dockerBuildTask)
```
## Building the docker images
The gradle task `generate-docker` allows to build all the docker images.
## Handling the OSS version
The docker images that are running using a jar need to the latest published OSS version on master. Here is how it is handle:
### Existing modules
The version should already be present. If a new version is published while a PR is open, it should generate a conflict, that will prevent you from
merging the review. There are scenarios where it is going to generate and error (The Dockerfile is moved for example), the way to avoid any issue
is to:
- Check the `.env` file to make sure that the latest version align with the version in the PR
- Merge the `master` branch in the PR and make sure that the build is working right before merging.
If the version don't align, it will break the remote `master` build.
The version will be automatically replace with new version when releasing the OSS version using the `.bumpversion.cfg`.
### New module
This is trickier than handling the version of an exiting module.
First your docker file generating an image need to be added to the `.bumpversion.cfg`. For each and every version you want to build with, the
docker image will need to be manually tag and push until the PR is merge. The reason is that the build has a check to know if all the potential
docker images are present in the docker repository. It is done the following way:
```shell
docker tag 7d94ea2ad657 airbyte/temporal:0.30.35-alpha
docker push airbyte/temporal:0.30.35-alpha
```
The image ID can be retrieved using `docker images` or the docker desktop UI.