tyler.durden/lynis
1
0
Fork 0
mirror of https://github.com/CISOfy/lynis.git synced 2025-07-31 01:34:23 +02:00
Code Issues Packages Projects Releases Wiki Activity

Updated Developer Guide (markdown)

Michael Boelen 2016-01-06 13:26:44 +01:00
parent 569a1d1754
commit 660a3ca2ed
1 changed files with 10 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
Developer-Guide.md

@ -21,15 +21,16 @@ Supporting documents and scripts are stored here.
Like any programming language, there are different ways to keep a project structured. It ranges from variable names, up to spacing. So we provide some guidelines to keep the structure and flexible enough for further expansion.
* Identitation is done with 4 spaces (no tabs)
* Indentation is done with 4 spaces (no tabs)
* Variables are capitalized, optional with an underscore to "split" words
# Contribute
## Preparing
First step to contributing via GitHub, is by forking the project. This creates a local version for you to experiment.
If you use Git already, simply clone the project to your local system. Otherwise work with a local copy. At the GitHub page you can download the master.zip file, containing the latest master release.
* Fork it ( https://github.com/CISOfy/lynis/fork )
* Create your feature branch (git checkout -b adding-my-new-feature)
## Making changes
@ -37,10 +38,15 @@ Next step is making your local changes and test them.
**Tip:** To simplify testing, you don't have Lynis to perform all tests. Use --tests-category or --tests to specifically decide what tests to run.
After you are done, commit the changes: (git commit -am 'Adding some feature or improvement')
## Testing
To improve the quality of your changes, tests should limit the amount of screen output. Important details should be logged to the log file, using the `logtext` function.
## Send in your changes
Last step is creating a pull request. Provide a clear description on what the pull request is about (and why). If you have multiple changes to different tests, split them into multiple pull requests. This way it is easier to check and implement them in the master branch.
Last step is creating a pull request. Provide a clear description on what the pull request is about (and why). If you have multiple changes to different tests, split them into multiple pull requests. This way it is easier to check and implement them in the master branch.
* Push to the branch (git push origin adding-my-new-feature)
* Create a new Pull Request