Version in “./docker-compose.yml” is unsupported.

Ich habe heute etwas mit Fossology gespielt. Genauer gesagt, wollte ich Fossology in Docker Containern starten und zwar mit Hilfe der Dateien, die von dem Projekt Fossology bereit gestellt werden.

Also fing ich an die entsprechenden Befehle in die Kommandozeile zu tippen:

$ git clone https://github.com/fossology/fossology.git
$ cd fossology
$ sudo docker-compose up

Beim letzten Befehl kam plötzlich eine Fehlermeldung:

ERROR: Version in "./docker-compose.yml" is unsupported. You might be seeing this error because you're using the wrong Compose file version. Either specify a version of "2" (or "2.0") and place your service definitions under the `services` key, or omit the `version` key and place your service definitions at the root of the file to use version 1.
For more on the Compose file format versions, see https://docs.docker.com/compose/compose-file

Mit Hilfe von

$ sudo docker-compose -v

docker-compose version 1.8.0, build unknown

fand ich heraus, dass die installierte docker-compose Version zu alt für die docker-compose.yml war, die in dem Fossology-Projekt lag. Also musste ich erstmal docker-compose updaten:

$ sudo curl -L https://github.com/docker/compose/releases/download/1.18.0/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose
$ sudo chmod +x /usr/local/bin/docker-compose

Danach konnte ich Fossology ohne Probleme in Docker Containern starten.

CMake: The ASM_NASM compiler identification is unknown

Neulich bekam ich beim Versuch, unter Ubuntu ein Makefile mit Hilfe von CMake zu erstellen, diese Fehlermeldung:

— The ASM_NASM compiler identification is unknown
— Didn’t find assembler
CMake Error at simd/CMakeLists.txt:41 (enable_language):
No CMAKE_ASM_NASM_COMPILER could be found.

Tell CMake where to find the compiler by setting either the environment
variable “ASM_NASM” or the CMake cache entry CMAKE_ASM_NASM_COMPILER to the
full path to the compiler, or to the compiler name if it is in the PATH.

— Configuring incomplete, errors occurred!

Die Lösung hier war, das Paket nasm zu installieren:

sudo apt install nasm

CMake und VS2017: could not find any instance of Visual Studio.

Vor kurzem bekam ich beim Versuch, ein Visual Studio 2017-Projekt mit CMake zu generieren, diese Fehlermeldung:

CMake Error at CMakeLists.txt:3 (project):
Generator

Visual Studio 15 2017 Win64

could not find any instance of Visual Studio.

— Configuring incomplete, errors occurred!

Die Fehlermeldung hat mich gewundert, da Visual Studio 2017 doch installiert war. Die Lösung bei mir war, dass ich noch die Komponente Visual C++ tools for CMake and Linux habe installieren müssen:

Jenkins master – Zu wenig Speicherplatz

Mit der Zeit kann es vorkommen, dass der frei verfügbare Speicherplatz auf dem Server auf dem Jenkins läuft, immer kleiner wird. Das kann unter Anderem auch an Jenkins selbst liegen.

In diesem Post möchte ich ein paar Hilfestellungen geben, wie man dieses Problem lösen und auch vorbeugen kann. Ich werde in diesem Post von meiner Jenkins Installation ausgehen, die auf einem Ubuntu-Server installiert ist. Auf anderen Linux- oder Windows-Servern muss man die vorgestellten Strategien jedoch anpassen.

Speicherhungrige Jobs finden

Auf meinem Ubuntu-Server ist Jenkins unter dem Pfad /var/lib/jenkins installiert. Unter diesem Ordner gibt es einen Ordner namens jobs, in dem es wiederum weitere Ordner gibt. Jeder dieser Ordner ist nach dem jeweiligen Job in Jenkins benannt. Wenn man also einen Job namens First Job hat, dann findet man unter jobs einen Ordner, der auch First Job heißt.

Mit dem Kommandos

cd /var/lib/jenkins/jobs

du -h –max-depth=1 | sort -hr

bekommt man nun eine Auflistung aller Ordner in jobs und die Größe aller Dateien zusammen vom jeweiligen Ordner.

Auf diese Weise kann man erkennen, welche Jobs den meisten Speicherplatz belegen. In meinem Fall ist das jedoch noch kein Problem. Will man jedoch für mehr Speicherplatz sorgen gib, kann es helfen, die Anzahl der Builds zu limitieren.

Anzahl der Builds limitieren

Standardmäßig speichert Jenkins jeden Build ab, den ein Job je ausgeführt hat. Insbesondere auch dann, wenn man anfängt, Artefakte zu archivieren (eine Post-build Aktion), kann der verfügbare Speicherplatz je nach Projekt sehr schnell klein werden. Wenn man aber die Anzahl der Builds limitiert, werden alte Builds von Jenkins automatisch gelöscht und es wird regelmäßig Speicherplatz wieder frei gelegt.

Um die Anzahl der Builds zu limitieren, muss man in einer Job-Konfiguration unter General einen Haken vor Discard old builds setzen und je nach belieben Werte einsetzen:

Anschließend das Speichern nicht vergessen 😉