Once a Docker Project or Source Code based Container is added to gopaddle, build scripts can be added to the container to specify a Source Control Repository from where the code needs to be cloned/pulled, the steps and Kubernetes environment to build the code and a Docker Registry to push the newly built Docker image.


  • Build Base Image : Build scripts are executed within a Container run from Build Base Image. It is optimal to prepare a Build Base Image with all the required build-tools pre-installed in the image so that you don't have to download and install those tools every time a build is run.

  • Runtime Base Image : Hardened images with minimal footprint. The artifacts built by running the build scripts are added to the Runtime Base Image and used for deployments.

  • Pre-build Script : Scripts to be run before running the build script. For example, scripts that install build tools. This is an alternate approach to preparing a Build Base Image. 

  • Build Script : Scripts to build the code to generate an artifact like jar, war, exe etc. This can also include unit test scripts. Build Succeeds only if the exit for the script is 0. 

  • Build Directory : Directory within the container to run the build script. By default, the source code will be pulled/cloned under /workspace/<projectname> directory. If a build directory is provided, then the source code will be pulled under /workspace/<builddirectory>/<projectname>. 

  • Output Directory : Directory where the artifacts will be available after build completes. By default, the output directory will be set to /workspace/<builddirectory>/<projectname>

  • Build Args : Build Arguments that are expected at the time of Docker build. If a Docker project with a pre-existing Dockerfile expects an argument to be passed to Dockerfile at the time of the build, Build Args field can be used to configure those arguments.

  • Custom Dockerfile path : If a Docker project contains Dockerfile in a path other than the project root directory, then the Custom Dockerfile path can be used to specific the Dockerfile relative to the project root. For eg, if the Dockerfile is present in folder build in the project root, then the Dockerfile path must be build/Dockerfile.

  • Distribution Registry : Registry where the final Runtime image needs to be pushed.

  • Build Environment : A Kubernetes Cluster where the build has to be run.

  • Build Capacity : Memory and CPU resources to be allocated for the build process.

As a best practice, avoid using the 'latest' tag name as some changes may get deployed unnoticed if any new updates were available and thus may result in faulty containers.


  1. A Container - Build Scripts are added to a Container resource. Build Scripts specify the steps to build and push the Docker Images. Hence a Container resource must be added prior to adding a Build Script. Follow Creating a Container article to create a new Container resource.

  2. A Source Control Account - In order to build code from a private repository which requires authentication, the source code account must have been registered as suggested in this article, prior to adding a build script.

  3. Add a Docker Registry - gopaddle follows a staged build approach where you can use different images for build time and for run time. The build scripts are executed within a container launched with the Build Base Image and the artifacts are copied to the Runtime Base Image to create the final Distribution Image. In order to use a custom Build Base Image or a Runtime Base Image, and to push the Distribution Image to a registry, the corresponding Docker Registries must have been added as suggested in this article. 

  4. A Kubernetes Cluster - gopaddle builds containers within your Kubernetes environments. Hence a Kubernetes Cluster must have been registered or created prior to adding a Build Script.

  5. An Allocation Policy - Allocation policies suggest the size of the build environments. You can choose a default size suggested by gopaddle or choose a custom size by Creating an Allocation policy

Steps to add build Scripts

1. Click the Containers option in the left navigation panel. For a newly added Container, you will see an Add Build Script option in the list. Click on the option to open the Build Script wizard.

2. In Step 1: Source Code Repository add the source code project from where the code needs to be cloned or pulled. If it is an open source public project, choose the Source Control Type as Unregistered. If it is a closed source project which requires authentication to clone/pull the code, then choose the Registered option. To use a registered source control account, you must have registered the Source Code Account as suggested in the article  Registering a Source Control Account.

In the Repository URL, provide the HTTP clone URL of the project.
Choose the Repository Origin Type and the Name to clone the project.

3. In Step 2: Build Image Configuration and in Step 3: Runtime Image Configuration you can choose an existing image or a custom image either from a public or a private Docker registry. To use a private Docker registry, you must add the registry by following the steps suggested in Add a Private Registry.
In Step 2: Add the Build Base Image, provide the image name along with the image tag.

In Step 3: Add the  Runtime Base Image, provide the image name along with the image tag.

4. In Step 4: Scripts, add build scripts to create an artifact from the code. Please refer to the terminologies section to fill the appropriate fields for the build script.
5. In Step 5: Distribution Registry, Add distribution image registry to where the newly built image needs to be pushed.

6. In Step 6: Build Environment, choose the Kubernetes Cluster where the build needs to be performed and the size of the build environment. In order to add a custom build capacity, please check the article on Creating an Allocation Policy. Click on Add build script to confirm and save the changes.

Did this answer your question?