It creates several virtual machines to simulate a target network. A Kali attacker will be spawned and use configured attacks to blast at the targets. Those attacks can be Kali command line tools, Caldera abilities or Metasploit tools.
is *not* included in the make test. But you can use it manually to verify your yaml config files. As they tend to become quite complex this is a time safer.
## More documentation
This README is just a short overview. In depth documentation can be found in the *doc* folder.
Documentation is using sphinx. To compile it, go into this folder and call
```
make html
```
Use your browser to open build/html/index.html and start reading.
Development happens in *feature branches* branched of from *develop* branch. And all PRs go back there.
The branch *release* is a temporary branch from *develop* and will be used for bug fixing before a PR to *main* creates a new release. Commits in main will be marked with tags and the *changelog.txt* file in human readable form describe the new features.
* As a user, the *main* branch is relevant for you
* Start a feature branch from *develop*
* When doing a hotfix, branch from *main*
### GIT
Branching your own feature branch
$ git checkout development
$ git pull --rebase=preserve
$ git checkout -b my_feature
Do some coding, commit.
Rebase before pushing
$ git checkout development
$ git pull --rebase=preserve
$ git checkout my_feature
$ git rebase development
Code review will be happening on github. If everything is nice, you should squash the several commits you made into one (so one commit = one feature). This will make code management and debugging a lot simpler when you commit is added to develop and main branches