The wireleap monolithic git repository containing the Wireleap software suite has been split, mainly into component repositories with a few more repositories based on maintainability, interoperability, separation of concerns and the DRY principle.
Splitting a monolithic repository, especially for a decentralized and distributed system composed of multiple components needing to interoperate with each other poses several additional challenges above the usual. Hence, there is a valid a reason why projects such as kubernetes use a mono-repository.
None the less, after weighing the pros and cons, we’ve decided to make the split mainly due to the following rationale:
Incrementally release code publicly under an open source license, and perform development in the open on said code - as opposed to using a band-aid approach of maintaining both public and private repositories.
Perform component specific semantically versioned releases as opposed to the entire software suite requiring a version bump. Additionally, improve versioning as a whole by having separate software versions, and inter-component communication versions.
Improved access control, maintainability, separation of concerns, flexibility, and forced code uncoupling.
Some of the post-split repositories have been released under the MIT license. Others will follow when they are ready…
|common||common go-packages which are used by 2+ components||MIT|
|client||wireleap client (incl. tun and intercept)||MIT|
|ps-dummy||example dummy payment system|
|ps-stripe||example stripe payment system|
|localtestnet||localtestnet and integration testing suite|
|gh-build||GitHub action for builds, unit-testing and releases||MIT|
In the mono-repository, all components shared the same semantic software release and protocol version. This actually worked quite well, was convenient, but not very optimal looking forward.
With the split and this release:
This is the last software version where all the latest component
software versions are equal. From now on, the component software
versions will be bumped individually as needed, along with the
component-component communication interaction versions.
A tricky part of the split was retaining the CI/CD flow with regards to integration testing.
The solution is best visualized in this sequence diagram showing the high-level flow and behind the scenes of the processes triggered when a Wireleap component repository receives a pull-request, a branch is merged into master, or a signed release git tag is pushed.
Note: The automatically built binaries have been mirrored to
enable inline upgrades of existing client / relay deployments.
Each repository now has a README.md housing the specific components documentation. The old documentation will be removed or updated shortly.
Issues will now be tracked per repository using the GitHub issue tracker feature.
Note: When upgrading the
wireleap client - if
wireleap_tun is owned
by root, it should be removed prior to performing an inline upgrade:
sudo rm $HOME/wireleap/wireleap_tun wireleap upgrade
wireleap_tunif root owned prior to upgrade.