Skip to content

Latest commit

 

History

History
103 lines (81 loc) · 3.34 KB

CONTRIBUTING.rst

File metadata and controls

103 lines (81 loc) · 3.34 KB

CaPython - Python interpreter for Camunda

Prerequisites

  1. GPG key associated with your GitHub account (how)
  2. CLA signed

How to sign CLA

  1. Fork the repository
  2. Clone the fork locally - git clone https://github.com/<you>/CaPython
  3. Visit the CLA.rst document in the repository
  4. Read the document
  5. Add a row with your data
  6. Commit the changes and sign the commit (git commit -m "message" --gpg-sign)
  7. Push the changes to your fork
  8. Open a pull request in CaPython repository

Create a development environment

For CaPython it's okay just to use a virtualenv package, however to fully test whether everything works as it should, using Docker is recommended as the project is distributed mainly as Docker images and the environment variables used for configuration are split so some apply for the starter code and some only for the runtime alone.

At the same time, it's targeting to be mainly compatible with Camunda's Docker image for BPM Platform image, not with the raw executables or JARs, but it the compatibility is possible, it should be implemented.

Linux and MacOS

  1. cd <cloned-repo>
  2. python -m virtualenv ~/env_capython
  3. source ~/env_capython/bin/activate
  4. pip install -r dev-requirements.txt

Windows

  1. cd <cloned-repo>
  2. python -m virtualenv %USERPROFILE%\env_capython
  3. %USERPROFILE%\env_capython\bin\activate
  4. pip install -r dev-requirements.txt

Modify some files and open a pull request

  1. Modify a file
  2. Add a file with changes - git add <file>
  3. Check the style by running - python style.py
  4. Commit the changes using - git commit -m "message" --gpg-sign
  5. Verify the commit(s) are changed with - git log --show-signature
  6. Push the changes to your fork - git push
  7. Navigate to https://github.com/KeyWeeUsr/CaPython/pulls
  8. Create a new pull request (don't forget to describe your changes)
  9. Wait for review (adjust after review if necessary)
  10. Wait for the merge

Commit naming guide

Use these tags for small/atomic commits to distinguish between various code patches:

  • [INIT] - the first commit in the repo
  • [CLA] - CLA related commits (signing, merging)
  • [ADD] - new features, files, etc
  • [FIX] - fixing a bug or incorrectly implemented behavior
  • [DEL] - only removing line(s)/file(s)
  • [REF] - patches related to large code or behavior refactoring that might break compatibility
  • [SUB] - git submodule related changes

Examples:

[INIT] Add initial empty commit
[CLA] <username> signed
[ADD] Add new special variable
[FIX] Fix passing values into task's runtime
[DEL] Remove deprecated code
[REF] Split single large file into package/modules
[SUB] Add submodule for X