Changes to Our Public GitHub Infrastructure
For some weeks we have been busy working on major infrastructure changes to our public GitHub repositories at Greenbone · GitHub.
New Branching Scheme
Many communities using Git and GitHub have renamed their default branch name of their repositories from master
to main
. Git and GitHub already switched to use main
for all new repositories. We decided to follow this path and changed the default branches of all our repositories to main
.
Changing the default branch name let us think about about our branching strategy in general. In the past, we used long term branches with a name version scheme like gvmd-9.0
. The version could be different between components. For example, gvm-libs-9.0
had to be used with openvas-scanner-5.1
. This created a lot of confusion as to which branch to use, even among our internal developers. Switching to a calendar based release versioning only slightly improved the situation.
So we took this as a chance to create a completely new branching scheme in conjunction with our ongoing efforts to strengthen our community. Our development branch will always be the main
branch. It will contain the code for the next release in the future. It is considered as unstable and should only be used by developers. We will not give any support for builds from main
branches.
For repositories where we maintain several releases at the same time like gvmd
, GSA
, openvas-scanner
, … we will have a stable
branch that contains code for the last and up-to-date released version. Users building from Git sources are encouraged to choose these branches. We will create bug-fix release from stable
branches regularly. Besides a stable
branch, there may be an additional oldstable
branch that contains code of the previous release. We will also create bug-fix releases from the oldstable
branch during its lifetime. As a consequence, this means we are going to maintain at most two releases for the community at the same time.
Summarized:
- The
main
branch is for future development. - The
stable
branch contains the up-to-date release and gets bug fixes regularly. - The
oldstable
branch contains the previous release and gets mostly security fixes.
Split of GSA and gsad
Something we had on our list for a long time was splitting our web server gsad written in the C programming language and our web application GSA written in JavaScript. At the time we were migrating from SVN to Git and GitHub, the web application GSA was still a static web page and heavily connected to our web server. At that time, the new dynamic JavaScript-based web application was still a draft. Therefore we decided to put both into the same Git repository.
After working more and more on the new JavaScript version of GSA, it became obvious that both have completely different tool chains and could be maintained independently but it was too late because we already migrated to GitHub. Thus, we hacked the C tool chain (CMake) around the JavaScript tool chain (nodejs, yarn) to still be able to ship both worlds in common releases. This created a big maintenance hurdle and after more than two years of discussing a split again and again, we finally decided to do it. By splitting both worlds we will be able to do more automation and reduce the maintenance costs. We are aware that this split will create some effort for users and packagers but it was a major drawback at our side and prevented some future work.
GSA can now be build with
yarn && yarn build
Afterwards, the created files in the build
directory must be copied to a specific directory to be provided by gsad
cp -r build/* $INSTALL_PREFIX/share/gvm/gsad/web/
$INSTALL_PREFIX
is /usr/local
by default and should be /usr
for Linux distributions like Kali Linux. The $INSTALL_PREFIX
can be set via CMake -DCMAKE_INSTALL_PREFIX
while building gsad
.