Skip to content

3.2 Git workflow

AlexanderZender edited this page Oct 19, 2022 · 1 revision

Introduction

This guide presents the git workflow any developer has to follow to contribute to the codebase.

How To Integrate

  • Working with issues
    • Any code submission is dependent on an open issue within the MetaAutoML repository
  • Master Branches should **always **be runnable --> for this goal we work in feature branches until Issue/Feature is finished:

Feature Branch

  • A feature branch is related to one issue
  • The target branch for this feature branch is the master. Therefore it is recommended to branch out from it
  • In this feature branch we will do all of our changes
  • Before we can make the changes visible on the master we need to make sure that all of our code is still runnable.

Testing

  • Test framework still under development --> custom test
  • Docker-compose test, build the branch using docker-compose and test that all functionalities are also working within docker-compose
  • After a successful check we can create a Pull-Request:

Docker-compose functionality test

When testing the docker-compose setup, make sure that all virtual disks and old images are deleted before building!

  • Start the docker-compose setup
  • Check that the default Titanic dataset was created
  • After a few minutes the dataset analysis for the default Titanic dataset should become available
  • Start a new training session with all adapters
  • After the training concluded, within the next few minutes the model analysis for the found models should become available
  • Download the model pipeline from the found models
  • Make Online predictions using the found models, and download the results
  • Delete the Titanic dataset, and check no training and dataset is available
  • Upload a new dataset, and check that it´s analysis becomes available after a few minutes
  • Check within the controller docker that no error are present

Pull-Request (PR)

  • The goals of a PR is to review the code changes, document them (PR should be also linked with the issue), and have an integration test
  • Please only create a PR when the feature is resolved in your opinion and you have made a short test if everything works as expected
  • When the branch is completes the checklist below, open a pull request and add AlexanderZender as a reviewer. After approving the PR code changes will visible on the target branch (master)

Pre-Pull-Request checklist

Before opening a PR make sure the following checklist has been completed:

  • The branch has an assigned issue
  • The code was tested, see chapter Testing above
  • The code is comform with the coding guideline, see chapter coding guideline