Add to_directory method to relevant object classes
[oam.git] / code / network-generator / CONTRIBUTING.md
1 # How to develop on this project
2
3 network_generation welcomes contributions from the community.
4
5 **You need PYTHON3!**
6
7 This instructions are for linux base systems. (Linux, MacOS, BSD, etc.)
8 ## Setting up your own fork of this repo.
9
10 - Clone this repo. 
11 ```
12   git clone "https://gerrit.o-ran-sc.org/r/oam" && (cd "oam" && mkdir -p `git rev-parse --git-dir`/hooks/ && curl -Lo `git rev-parse --git-dir`/hooks/commit-msg https://gerrit.o-ran-sc.org/r/tools/hooks/commit-msg && chmod +x `git rev-parse --git-dir`/hooks/commit-msg)
13 ```
14 - Enter the directory `cd oam/code/network-generation`
15 - Please see [O-RAN-SC Code Contributions Tutorial](https://wiki.o-ran-sc.org/display/ORAN/Tutorial%3A+Making+code+contributions+to+O-RAN+open+source+project)
16
17 ## Prerequisites
18
19 ```
20 sudo apt install python3.10-venv
21 ```
22
23 ## Setting up your own virtual environment
24
25 Run `make virtual_env_4_oam` to create a virtual environment.
26 then activate it with `source .venv/bin/activate`.
27
28 ## Install the project in develop mode
29
30 Run `make install` to install the project in develop mode.
31
32 ## Run the tests to ensure everything is working
33
34 Run `make test` to run the tests.
35
36 ## Create a new branch to work on your contribution
37
38 Run `git checkout -b my_contribution`
39
40 ## Make your changes
41
42 Edit the files using your preferred editor. (we recommend VIM or VSCode)
43
44 ## Format the code
45
46 Run `make fmt` to format the code.
47
48 ## Run the linter
49
50 Run `make lint` to run the linter.
51
52 ## Test your changes
53
54 Run `make test` to run the tests.
55
56 Ensure code coverage report shows `100%` coverage, add tests to your PR.
57
58 ## Build the docs locally
59
60 Run `make docs` to build the docs.
61
62 Ensure your new changes are documented.
63
64 ## Commit your changes
65
66 This project uses [conventional git commit messages](https://www.conventionalcommits.org/en/v1.0.0/).
67
68 Example: `fix(package): update setup.py arguments 🎉` (emojis are fine too)
69
70 ## Push your changes to your fork
71
72 Run `git push origin my_contribution`
73
74 ## Submit a pull request
75
76 On github interface, click on `Pull Request` button.
77
78 Wait CI to run and one of the developers will review your PR.
79 ## Makefile utilities
80
81 This project comes with a `Makefile` that contains a number of useful utility.
82
83 ```bash 
84 ❯ make
85 Usage: make <target>
86
87 Targets:
88 help:              ## Show the help.
89 install:           ## Install the project in dev mode.
90 fmt:               ## Format code using black & isort.
91 lint:              ## Run pep8, black, mypy linters.
92 test: lint         ## Run tests and generate coverage report.
93 watch:             ## Run tests on every change.
94 clean:             ## Clean unused files.
95 virtual_env_4_oam: ## Create a virtual environment.
96 release:           ## Create a new tag for release.
97 docs:              ## Build the documentation.
98 switch-to-poetry:  ## Switch to poetry package manager.
99 init:              ## Initialize the project based on an application template.
100 ```
101
102 ## Making a new release
103
104 This project uses [semantic versioning](https://semver.org/) and tags releases with `X.Y.Z`
105 Every time a new tag is created and pushed to the remote repo, github actions will
106 automatically create a new release on github and trigger a release on PyPI.
107
108 For this to work you need to setup a secret called `PIPY_API_TOKEN` on the project settings>secrets, 
109 this token can be generated on [pypi.org](https://pypi.org/account/).
110
111 To trigger a new release all you need to do is.
112
113 1. If you have changes to add to the repo
114     * Make your changes following the steps described above.
115     * Commit your changes following the [conventional git commit messages](https://www.conventionalcommits.org/en/v1.0.0/).
116 2. Run the tests to ensure everything is working.
117 4. Run `make release` to create a new tag and push it to the remote repo.
118
119 the `make release` will ask you the version number to create the tag, ex: type `0.1.1` when you are asked.
120
121 > **CAUTION**:  The make release will change local changelog files and commit all the unstaged changes you have.