|
| 1 | +# relecov-tools: Contributing Guidelines |
| 2 | + |
| 3 | +## Contribution workflow |
| 4 | + |
| 5 | +If you'd like to write or modify some code for relecov-tools, the standard workflow is as follows: |
| 6 | + |
| 7 | +1. Check that there isn't already an issue about your idea in the [relecov-tools issues](https://github.com/BU-ISCIII/relecov-tools/issues) to avoid duplicating work. **If there isn't one already, please create one so that others know you're working on this**. |
| 8 | +2. [Fork](https://help.github.com/en/github/getting-started-with-github/fork-a-repo) the [relecov-tools repository](https://github.com/BU-ISCIII/relecov-tools/) to your GitHub account. |
| 9 | +3. Make the necessary changes / additions within your forked repository following the [code style guidelines](#code-style-guidelines). |
| 10 | +4. Modify the [`CHANGELOG`](../CHANGELOG.md) file according to your changes in the appropiate section ([X.X.Xdev]), you should register your changes regarding: |
| 11 | + 1. Added enhancements |
| 12 | + 2. New modules |
| 13 | + 3. Fixes |
| 14 | + 4. Removed stuff |
| 15 | + 5. Requirements added or version update |
| 16 | +5. Update any documentation as needed. |
| 17 | +6. [Submit a Pull Request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request) against the `develop` branch and send the url to the #pipelines-dev channel in slack (if you are not in the slack channel just wait fot the PR to be reviewed and rebased). |
| 18 | + |
| 19 | +If you're not used to this workflow with git, you can start with: |
| 20 | + |
| 21 | +- Some [docs in the bu-isciii wiki](https://github.com/BU-ISCIII/BU-ISCIII/wiki/Github--gitflow). |
| 22 | +- [some slides](https://docs.google.com/presentation/d/1PruqGxPQVxtNcuEbOd86mylXorgYIU5a/edit?pli=1#slide=id.p1) (in spanish). |
| 23 | +- some github generic docs [docs from GitHub](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests). |
| 24 | +- even their [excellent `git` resources](https://try.github.io/). |
| 25 | + |
| 26 | +### relecov-tools repo branches |
| 27 | + |
| 28 | +relecov-tools repo works with a two branching scheme: `main` and `develop`. |
| 29 | + |
| 30 | +- `main`: stable code only for releases. |
| 31 | +- `develop`: new code development for the different modules. |
| 32 | + |
| 33 | +You need to submit your PR always against `develop`. Once approbed, this changes must be **`rebased`** so we do not create empty unwanted merges. |
| 34 | + |
| 35 | +## Tests |
| 36 | + |
| 37 | +When you create a pull request with changes, [GitHub Actions](https://github.com/features/actions) will run automatic tests. |
| 38 | +Typically, pull-requests are only fully reviewed when these tests are passing, though of course we can help out before then. |
| 39 | + |
| 40 | +There are typically two types of tests that run: |
| 41 | + |
| 42 | +### Lint tests |
| 43 | + |
| 44 | +We use black and flake8 linting based on PEP8 guidelines for python coding. You can check more information [here](https://github.com/BU-ISCIII/BU-ISCIII/wiki/Python#linting). |
| 45 | + |
| 46 | +### Code tests |
| 47 | + |
| 48 | +Download, read-lab-metadata, map and validate modules are executed using a test dataset. |
| 49 | + |
| 50 | +Anyhow you should always submit locally tested code!! |
| 51 | + |
| 52 | +### New version bumping and release |
| 53 | + |
| 54 | +In order to create a new release you need to follow the next steps: |
| 55 | + |
| 56 | +1. Set the new version according to [semantic versioning](https://semver.org/), in our particular case, changes in the `hotfix` branch will change the PATCH version (third one), and changes in develop will typicaly change the MINOR version, unless the developing team decides otherwise. |
| 57 | +2. Create a PR bumping the new version against `develop`. For bumping a new version just change [this line](https://github.com/BU-ISCIII/relecov-tools/blob/09c00c1ddd11f7489de7757841aff506ef4b7e1d/setup.py#L5) with the new version. |
| 58 | +3. Once that PR is merged, create via web another PR against `main` (origin `develop`). This PR would need 2 approvals. |
| 59 | +4. [Create a new release](https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository) copying the appropiate notes from the `CHANGELOG`. |
| 60 | +5. Once the release is approved and merged, you're all set! |
| 61 | + |
| 62 | +PRs from one branch to another, like in a release should be **`merged`** not rebased, so we avoid conflicts and the branch merge is correctly visualize in the commits history. |
| 63 | + |
| 64 | +### Code style guidelines |
| 65 | + |
| 66 | +We follow PEP8 conventions as code style guidelines, please check [here](https://github.com/BU-ISCIII/BU-ISCIII/wiki/Python#pep-8-guidelines-read-the-full-pep-8-documentation) for more detail. |
| 67 | + |
| 68 | +When developing new code, we strongly recommend to implement LogSum() functions from log_summary.py instead of the classic python logging in order to keep track of all the warnings and errors that may appear during any of the processes. |
| 69 | + |
| 70 | +## Getting help |
| 71 | + |
| 72 | +For further information/help, please ask on the `#pipelines-dev` slack channel or write us an email! ( [[email protected]](emailto:[email protected])). |
0 commit comments