Swiss FluxNet

Search

General Format

Created On
Last Updated On
byLukas Hörtnagl
Print
You are here:

Software organization using Gitlab and GIN

Self-written software for data acquisition must be stored, maintained and versioned properly. In the grassland group, we use two tools to accomplish this:

  • Gitlab (storage, versioning)
  • GIN (deployment documentation)

All self-written script or programs (subsequently referred to as programs only) have to be stored in a gitlab repository (gitlab how-to). When you deploy a program on a data acquisition system (computer, datalogger, arduino, etc.), you have to create a fieldbook entry in GIN with the SW_MOD event-tag (gin tutorial) and an URL link pointing to the exact commit of the program repository. Similarly, if you update a configuration-file for a program, you have to create a fieldbook entry in GIN with the CONFIG event-tag and the config-file attached.

As such it is clearly documented when which version of which program was installed on which data acquisition system

To simplify this organisation, some standards have to be met, which are described in the following sections.

Naming of programs and configurations

Programs used on multiple sites

Programs that are (potentially) used on multiple sites must have a site-unspecific name, i.e. the site-name or project-name should not be present. Due to the versioning in git repositories, also version numbers in the file name are obsolete.

ProgramName.file extension

whereby

ProgramName … due to the variety of possible programs, the naming is not strictly regulated. Nevertheless, the program name must clarify what the program is doing (e.g. read, write, control, etc.) and for which instrument or system (as described in Section 2.4.1, e.g. sonic, TrHW, etc.) it was designed for. The ProgramName shall not contain information about SITE or VERSION.
file extension … if necessary

Site-specific programs

SiteID_ProgramName_Location.file extension

whereby

SiteID … as given here
ProgramName … due to the variety of possible programs, the naming is not strictly regulated. Nevertheless, the program name must clarify what the program is doing (e.g. read, write, control, check etc.) and for which instrument or system (as described here, e.g. sonic, TRHW, etc.) it was designed for.
Location … as given here
file extension … if necessary

Scripts and programs  which are specific for a special site and device and or data acquisition e.g. a logger program of a CR1000 logger that includes the (mostly) unique sensor configuration of a site and system.

Configuration files

Some programs use configuration files, mainly for these reasons:

  • large number of settings that cannot be passed by command line arguments
  • generalization of the program to multiple sites, where only the configuration is site-specific

SiteID_ProgramName.file extension

whereby

SiteID … as given here
ProgramName … must be the ProgramName of the program reading from it
file extension … must be .rc or .config (where possible)