-
Notifications
You must be signed in to change notification settings - Fork 4
3.2 Git workflow
AlexanderZender edited this page Oct 19, 2022
·
1 revision
This guide presents the git workflow any developer has to follow to contribute to the codebase.
- 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:
- 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.
- 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:
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
- 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)
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