GitHub Infrastructure Changes

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.


  • 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.


Do you have any questions or comments? Please add them in the discussion topic.