How would you like this repository set up? I have whonix forked, and could add automated testing in a seperate folder. I can create a public repository as well and am happy to give write access to @Patrick
Do we want a jenkins server set up as a CI/CD pipe for source code PRs? Jenkins is a bit new to me but I am happy to take a stab at this.
I would prefer to write ruby, and follow their model of
--Given /^I capture all network traffic$/ do
@sniffer = Sniffer.new("sniffer", $vmnet)
but without all the ivars
Once it is configured, I feel confident I can write effective tests productively. But getting it spun up may be a bit of a challenge
Could you please join that forum thread and view that git repository for your oversight?
That is, because I am not the most senior python programmer and also this test suite seems uncharted territory (at least for me). Therefore it would be good if we can give good feedback to the students early so fundamental issues are noticed early.
I will join the thread and do my best. I was really hoping to do this in ruby, as I am very experienced with ruby (many thousands of hours). Ive only spent a few dozen hours or so with python. But the same principles should apply I think.
After discussion with @Patrick and @fahr3n, it seems as though we have a more clear idea of how to move forward and what we can do to actually make this happen. At a high level my primary objectives are:
After successfully configuring vagrant and libvirt to work in my environment, I began researching heavily what it will take to run an automated testing suite with CI using a Vagrant VM. Essentially, I have having to pivot the CI tooling from TravisCI to Jenkins for this job.
Jenkins already has a plugin for Vagrant for this sort of thing, and it seems nearly impossible with TravisCI.
With that said, these are the action items required from me to move forward with objective #1.
Stand up local jenkins server (done)
Connect vagrant plugin with Jenkins to build VM in CI environment (in progress)
Successfully run automated tests in CI VM
After that is complete, I plan to start integrating test cases.
Feedback, comments, concerns, and questions are all welcome
I recognize this is a huge repository and splitting out the toaster (test suite) part makes very much sense. Otherwise it’s hard to see through / understand / make changes indeed. However, for reasons of license compliance, authorship recognizance, and diff viewing… Could you please:
fork (gitlab clone) the repository as is ( doesn’t matter gitlab.com, github.com, that is easily changed later),
reupload that repository somewhere as is (),
keep all git history,
the COPYING file must not be deleted,
go on a deletion spree (delete all files which are not going to be needed in the standalone WhonixToaster and git commit that mass deletion),
add changes on top which are required to make this Whonix specific (can be in a single commit)?
That would help to keep git history intact, authorship recognization intact, could answer the question a few years later “which commit was forked from” and “what are Whonix’s changes since”.