-
Notifications
You must be signed in to change notification settings - Fork 0
Releasing a Build
In general we release from the master branch. Release involves running build, tests, creating a docker container, and then publishing the docker container.
In order to ensure we don't pick up any uncommitted changes, the first step is to clone the repository to a new location, and work within that clone.
git clone https://github.com/GoogleCloudPlatform/datalab.git release
cd release
source tools/initenv.sh
In this step, the sources are built, a new docker container is built, and staged in the container registry using the user name as the tag, specifically gcr.io/cloud_datalab/datalab:$USER. This allows using the tagged image to validate it, before promoting it to be the latest.
cd $REPO_DIR/sources
./build.sh
cd $REPO_DIR/containers/datalab
./build.sh
./stage.sh [feature]
If the feature flag is specified when deploying, the tag includes both user name and feature name, specifically, gcr.io/cloud_datalab/datalab:$USER_feature. This allows multiple tagged images per user, one per feature.
Validating the docker container involves local running as well as running on the cloud.
Run the docker container using the following command:
cd $REPO_DIR/container/datalab.sh
./run.sh
Deploy the docker container via the deployer application.
Navigate to https://cloud-datalab-deploy.appspot.com?container=container_including_tag[&name=instance]
Use the app to sign in, pick a cloud project to deploy, and then deploy. This will create an AppEngine application module named "datalab" using the specified container. By default the version of the deployed AppEngine module is "main", but that can be changed by specifying a name querystring parameter when using the deployer application.
This step builds the same docker container as before (reusing the already created layers) and then releases the resulting image tagged as gcr.io/cloud_datalab/datalab:latest.
cd $REPO_DIR/containers/datalab
./release.sh
cd $REPO_DIR/content
./publish.sh