2016-04-21 9 views
2

Wir haben ein Code Composer Studio (Eclipse) -Projekt, das CMAKE verwendet, um Makefiles zu erstellen und zu erstellen. Das Projekt wird wie erwartet kompiliert, wenn das Projekt manuell auf den Jenkins-Slave (Win10 x64) importiert und von der Befehlszeile aus ausgeführt wird, aber fehlschlägt, wenn der Build von Jenkins verarbeitet wird. Der Fehler folgt immer demselben Muster: Ein einzelner Buchstabe wird aus dem Pfad einer Objektdatei entfernt. Beispiel: wird [Repo direcory]/Cockpit_Scaling_and_Exceedance_ata.dir, und die Verknüpfung schlägt fehl, da die referenzierte Objektdatei nicht gefunden werden kann.Jenkins löscht einen Brief aus Dateipfaden

Ich habe sichergestellt, dass es keine Unterschiede zwischen den Kontoumgebungsvariablen und den Systemumgebungsvariablen gibt, und habe den Jenkins Service auch so konfiguriert, dass das Administratorkonto auf dem Slave anstelle von SYSTEM verwendet wird, um so viele Unterschiede zwischen den beiden zu beseitigen Jenkins und die Befehlszeile wie möglich.

Das Projekt wird erfolgreich mit einem unserer anderen Jenkins-Slaves (auch Win10 x64) erstellt, so dass wir wissen, dass es kein Windows 10-Problem oder ein Problem mit unserer Jenkins-Konfiguration ist. Da ich keine Unterschiede zwischen den Konfigurationen der beiden Slave-Geräte feststellen kann, hatte ich gehofft, dass jemand in der Lage sein könnte, irgendwo einen Vorschlag für dieses Pfadproblem zu machen.

Antwort

0

Ich habe nie herausgefunden, warum die Pfade zu Objektdateien manipuliert wurden, aber ich habe das Projekt erfolgreich über Jenkins auf dem Slave erstellt. Ich habe lediglich alle Systemumgebungsvariablen in Benutzerumgebungsvariablen geändert. Ich kopiere, also weiß ich, dass sich die Variablen nicht geändert haben.

Ich habe keine Ahnung, warum dies dieses Problem behoben, wie ich einen whoami Aufruf am Anfang des Builds eingefügt hatte, um zu bestätigen, dass Jenkins tatsächlich als ein Benutzer und nicht System ausgeführt wird. Ich denke, ab diesem Punkt werden alle meine Umgebungsvariablen spezifisch für einen Benutzer sein und nicht SYSTEM ...

EDIT: Das Problem ist zurückgekehrt. Ich habe keine weiteren Fortschritte beim Aufspüren der Ursache dieses Problems gemacht, aber ich habe festgestellt, dass ich dieses Symptom nicht sehe, wenn ich die Skripte in einer Bash-Umgebung statt einer Windows-Eingabeaufforderung abspiele. Zum Glück für mich wurden die Skripts so geschrieben, dass sie in beiden Umgebungen ausgeführt werden können, so dass meine Kollegen stattdessen bash für sie verwenden.

Verwandte Themen