Skip to content

Home

Jump to bottom
John Mercier edited this page Feb 5, 2017 · 30 revisions

Welcome to the graph-dsl wiki! graph-dsl is a quick and easy way to create graphs and perform algorithms on them. It creates a traditional set of vertices and edges and provides a lot of groovy magic to deal with them.

#Status ##Master

  • Build Status

##Develop

  • Build Status

#Continuous Integration

graph-dsl uses travis-ci to build, test, and run static code analysis for sonarqube.

Development

Workflow

This project uses gitflow-avh with github pull requests. For these to work together some rules should be followed.

  • Pull requests are used to run checks and allow comments. Sonar adds comments for issues it finds.
  • If a pull request resolves and issue it should have (resolve #X) to close the issue in github when it is merged.
  • For features pull requests should be made against develop.
  • For releases and hotfixes pull requests should be made against master.
  • Releases should be made for each feature merged. There should only be bug fixes release branch.
  • Documentation should be updated to reflect the new release.
  • Internal pull requests should not be merged through github.com. Instead, use gitflow to do the merge. Once gitflow merges the branches, github.com should be automatically marked as merged by github.com.

I'm not sure how to handle external pull requests yet.

features

bugs

hotfixes

releases

Features and bug fixes should be released as soon as they are merged to develop. This is so they can be continuously delivered and to make semantic versioning much easier.

git flow release start <new version number>

This creates a release branch from develop. The version number is automatically "bumped" by the gradle git flow plugin: apply plugin: 'com.github.amkay.gitflow' an example of what the version is

Inferred version 0.2.0-pre.7+sha.22c2439

The version on the release branch is a pre-release. Once git flow release finish is called it becomes a real release.

Once a release branch is created it should be pushed to github.

git push --set-upstream origin release/0.2.0

This will create the branch on github and push it.

Now a pull request should be created between the release branch and master. This is to review all of the changes before they are finally put into master. It also allows any issues filed to automatically be closed.

Perform all actions needed to complete the release. There should be very little coding since the feature should already work. Fixing minor bugs is ok though.

It is important to remember to update the README.md file with release information. Also ensure any changes to the usage section are made.

Once the release is ready complete it. Use -k to make sure the release branch can be pushed which merges the pull request.

git flow release finish <release name> -k

Make sure all branches and tags are pushed to github.

git push --all
git push --tags

This should result in the pull request being merged and a release being added to github. Delete the release branch.

git flow release delete <release name> -r

Edit the release in github updating it with release notes. If it is a pre-release mark it in github.

Issue with pull requests

The normal gitflow workflow breaks pull requests in github. Here is the workaround.

//use the -k flag to keep the feature branch
git flow feature finish test -k
//after all the merging is done, the PR should be marked as 'merged', so you can delete the remote branch
git flow feature delete test -r
Clone this wiki locally