Skip to content

Contributing guidelines & workflows

Sam Borms edited this page Oct 4, 2021 · 18 revisions

General remarks

  • Make sure to follow the PEP 8 styleguide if you make any changes to Cobra (we plan use the Black linter).
  • You should also write or modify unit test for your changes.
  • We are using templates when submitting PR or Issue, please follow them.
  • Make sure you add Issue number with # to the commit message.
  • For versioning, we are following the rules of semantic versioning.
  • We are following Gitflow workflow.

Contribution from outside of Python Prediction

The preferred way to contribute to Cobra is to fork the main repository on GitHub, then submit a "pull request" (PR). The first step is to get a local development copy by installing Cobra from source through the following steps:

  • Fork the project repository. For more details on how to fork a repository see this guide.
  • Clone your fork of Cobra's repo.
  • Open a shell and navigate to the folder where this repo was cloned in.
  • Once you are in the folder, execute pip install --editable ..
  • Create a feature branch to do your development.
  • Once you are finished developing, you can create a pull request from your fork (see this guide for detailed instructions).
  • To avoid duplicating work, it is highly recommended that you search through the issue tracker and/or the PR list. If in doubt, you can always reach out to us through email ([email protected]).

Contribution from our team members

  • Pull latest version of development branch to your local repository.
  • Create a feature branch from the develop branch (follow the correct naming).
  • Push your feature branch to the remove and request pull request (PR).
  • PR has to have at least one reviewer. Once your PR has been approved, your work is done.
  • After, the feature branch can be deleted.

Release workflow

  • Once we finish our milestone (has name of next release), we will create a release.
  • Before merging develop into master branch, it is recommended to first merge master into the develop branch to avoid polluting the master branch (see explanation).
  • After PR is approved, we tag the version as a release.
  • GitHub Actions pipeline will build and release the package on pip. Our PyPI account is python-admin (see our internal company wiki for access).
  • Manual release is also an option.

GitHub Actions

  • development_CI.yaml - runs Pylint and pytest whenever we push to develop.
Clone this wiki locally