Hier kann über allgemeine Themen diskutiert werden, die sonst in kein Forum passen.
Insbesondere über Szene, Games, Kultur, Weltgeschehen, Persönliches, Recht, Hard- und Software.
Ich versuche mich gerade daran das Github Actions zum Laufen zu kriegen. Aber ich werde einfach nicht schlau draus. Tutorials sind kaum zu finden. Brauchbare Antworten für die Fehlermeldungen noch viel weniger. Und aus der Manual werde ich einfach nicht schlau.
Die haben da zwar wunderbare Templates. Aber auch da endet es mit einer nichtssagenden Fehlermeldung. Process completed with exit code 127 zum Beispiel. Nicht dass man da irgendwie rausfinden könnte was Fehler 127 wirklich ist ...
Sagen wir mal ich nehme das Github Template für C / C++ und Make. Dann sieht das Script by Default eigentlich danach aus als ob es alles hat was man braucht. Make ist ja der Konsolenbefehl um das Kompilieren zu starten. So tuts auf meinem Ubuntu, so tuts auch auf Windows.
Und trotzdem schmeisst es mir eben Fehler 127 statt wenigstens mal fertig zu kompilieren. Und es macht mich narrisch dass ich nicht rausfinden kann was ich hier übersehe.
Was übersehe ich denn hier? Wieso schmeisst es mir einen Fehler statt zu kompilieren?
Und wir benötigen eigentlich auch noch externe precompiled Libs fürs builden. Und dazu finde ich überhaupt nichts.
Warum er dir hier aber einen Fehler wirft, kann ich dir nicht sagen, ohne dass du das Repo postest, wo der Code ausgeführt wird und man sich mal die vollständige Ausgabe eines CI Runs angucken kann. Kannst du die mal posten? GGf. am besten mit nem direkten Link zu deinem CI run?
War mal MasterQ32, findet den Namen aber mittlerweile ziemlich albern…
mkdir ~/blender-git/lib
cd ~/blender-git/lib
svn checkout https://svn.blender.org/svnroot/bf-blender/trunk/lib/linux_centos7_x86_64
EDIT; ich habe hier auch noch einen alten Versuch im Repo, unbenannt in .old . Da hat es immer gemeckert dass ein Pfad fehlt. Und der der das gemacht hat hat einfach keine Zeit mehr für sowas ...
Run ./configure
./configure
shell: /usr/bin/bash -e {0}
/home/runner/work/_temp/a08a1b12-5b27-4891-bb35-362d0a72f674.sh: line 1: ./configure: No such file or directory
Error: Process completed with exit code 127.
./configure: No such file or directory. Wenn ich mir dein Repo so angucke, ist da auch keine Datei namens configure ;)
Ah, das ist quasi wie beim von Hand Builden auch, einfach die nötigen Befehle auflisten? Danke dir, werde ich mal morgen durchexerzieren. Und gebe dann Bescheid ob ich es zum Laufen bekommen habe :)
Tiles hat geschrieben: ↑07.07.2021, 17:46
Ah, das ist quasi wie beim von Hand Builden auch, einfach die nötigen Befehle auflisten? Danke dir, werde ich mal morgen durchexerzieren. Und gebe dann Bescheid ob ich es zum Laufen bekommen habe :)
Exakt dies :)
War mal MasterQ32, findet den Namen aber mittlerweile ziemlich albern…
So. Im Moment verheddert es sich noch in den Pfaden. Das cd wieder zurück ins repo um den Build Prozess zu starten scheitert.
Da blicke ich eh noch nicht durch. uses: actions/checkout@v2 zieht ja schon das Repo in den Runner. Sprich ich könnte mir ja eigentlich den Teil mit dem Clone sparen. Nun brauche ich aber meine Libs neben dem Repo Ordner. Wie müsste denn dann der Pfad lauten?
Und wieder eine halbe Stunde gewartet bis die Libs auf dem Runner sind. Und wieder gescheitert, seufz ^^
Github Actions kennt kein Make Update? WTF? Der Befehl geht definitiv. Simmer ja wieder froh dass BFA keine Submodule verwendet. Mit Blender hätte ich jetzt ein Problem, der zieht damit seine Addons rein.
Ich empfehle dir auch stark, NICHT am homeverzeichnis dinge zu tun, sondern alles mit relativen pfaden zu machen. du hast keine garantie über das working dir. Zudem befindest du dich nach nach dem checkout-step schon im passenden verzeichnis und "git clone" wurde schon durchgeführt.
Die Libs müssen halt an der richtigen Stelle relativ zum Repo sein. Sonst werden die nicht gefunden. Ein einfaches run svn checkout würde die mir ja ins Repo importieren. Deswegen das gehampel mit dem cd.
Und wie gesagt, make update schmeisst einen Fehler.
Aber an der Hürde war ich schon vorbei. Der letzte Fail war ja schon im Buildprozess selber. Python scheint nicht gefunden zu werden. Was seltsam ist weil Ubuntu eigentlich mit Python kommt. Im Moment versuche ich das zu installieren.
Die absoluten Pfade werde ich ändern sobald das endlich mal tut. Den absoluten Pfad hatte ich mir mittels pwd gezogen. Der scheint zu stimmen.
Mit der Manual komme ich leider überhaupt nicht zurecht. Das ist imho irgendwie im Stil geschrieben dass du schon alles wissen musst um überhaupt die Manual zu verstehen.
name: build_linux
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]
jobs:
build:
runs-on: ubuntu-latest
strategy:
# You can use PyPy versions in python-version.
# For example, pypy2 and pypy3
matrix:
python-version: [2.7, 3.7]
steps:
- uses: actions/checkout@v2
- name: Set up Python ${{ matrix.python-version }}
uses: actions/setup-python@v2
with:
python-version: ${{ matrix.python-version }}
# You can test your matrix by printing the current Python version
- name: Display Python version
run: python -c "import sys; print(sys.version)"
#steps:
#- uses: actions/checkout@v2
#- name: current directory
# run: pwd
- name: make libs dir
run: mkdir /home/runner/work/Bforartists/libs
- name: change dir to lib
run: cd /home/runner/work/Bforartists/libs
- name: checkout
run: svn checkout https://svn.blender.org/svnroot/bf-blender/trunk/lib/linux_centos7_x86_64
- name: change dir to make
run: cd /home/runner/work/Bforartists/Bforartists
#- name: make update
# run: make udpate
- name: make
run: make
- name: Upload Build
uses: actions/upload-artifact@v2
with:
name: Bforartists-Release-${{ runner.os }}
path: ${{ env._MAIN_DIR }}/build_linux/bin/
Die wollen mich verarschen. Python 3 ging nicht zu installieren. Was ich noch verstehen kann, denn Ubuntu kommt meines Wissens nach halt schon mit einer 3er Python version. Python 2 hat installiert. Aber es failt immer noch daran dass angeblich Python nicht gefunden wird :/
Jetzt bin ich erst mal ratlos. Wie komme ich denn an die Error Logs im Runner? ^^
Tja, das scheint mir weniger ein Problem von fehlender Python Installationen auf dem Ubuntu Gastsystem zu liegen. Sondern der findet die Python Libraries in den precompiled Libs nicht. Also das was ich per svn reinziehe.
Die Libs sind aber definitv da, sonst würde es schon vorher meckern. Die andren Module werden gefunden. Es scheitert erst an Python. Und ich habe grade gecheckt ob es zwischenzeitlich Änderungen an den Libs gegeben hat. Aber auf Ubuntu ist alles so wie es gehört. Und auf Ubuntu kompiliert es auch nach wie vor ohne Fehler durch.
Es ist zum Mäuse melken ^^
EDIT runs-on: ubuntu-latest versus Could NOT find PythonLibsUnix. Was zur Hölle sucht Actions nach Unix Libs? O_O
Ich strecke die Waffen. Da ist für mich kein Rankommen. Wenn Actions die Config versaut die unter Ubuntu tadellos funktioniert dann war es das wohl einfach.
Tiles hat geschrieben: ↑08.07.2021, 12:47
Ich strecke die Waffen. Da ist für mich kein Rankommen. Wenn Actions die Config versaut die unter Ubuntu tadellos funktioniert dann war es das wohl einfach.
Danke für deine Hilfe bis hierher xq :)
Klingt für mich nach einer Crunch Time, was das Buildsystem angeht. Wenn ihr nur auf einer spezifischen Distro in einer spezifischen Version bauen könnt, ist da echt dringend Arbeit notwendig. Bequemer Build wird leider von vielen Projekten massiv vernachlässigt, und eine Anleitung, die *nur* auf Ubuntu baut und absolute Pfade verwendet, schreit nach dringend neu und sauber machen.
Das gute an einem CI ist: Du bekommst ein clean-slate System üblicherweise mit Minimalsystem. Damit hast du implizite Dependencies rausgeworfen
War mal MasterQ32, findet den Namen aber mittlerweile ziemlich albern…
Also der Build Process von Blender den wir ja auch verwenden ist wirklich straight forward, eigentlich narrensicher, und funktioniert auch so ziemlich überall. Und benutzt natürlich auch relative Pfade. Die absoluten Pfade die ich hier nehme ist nur weil ich nicht wusste welche Ordnerstruktur Github Actions verwendet. Und der einzige Ort auf der ganzen Welt wo es nicht funktioniert ist im Moment Github Actions. Wir hatten das auch schon auf Travis und noch einer anderen Buildplattform.
Das hat mir übrigens keine Ruhe gelassen. Was hier querschiesst ist eindeutig Github Actions. Ich brauche meine Libs einfach relativ zum Repository auf gleicher Ordnerebene. Wie oben schon gezeigt. Die nutzen mir gar nichts wenn Actions mir das ins Repo reinklont. Da werden sie nicht gefunden. Und das ist hier grade mein Problem. Die Libs sind nicht da wo sie gesucht werden.
Github Actions macht mier hier nur Änderungen in Bforartists/Bforartists wie ich grade rausgefunden habe. Mein CD funktioniert schlicht nicht. Obwohl es als Erfolg gekennzeichnet ist. Sieht man sehr schön. Ich wechsle nach Bforartists/Lib. Juckt Actions nicht die Bohne, das ist immer noch in Bforartists/Bforartists
Und somit kann ich das mit Actions eigentlich vergessen. Ich kriege meine Libs nicht auf den Platz wo sie hingehören: ich kann noch nicht mal checken ob sie nicht doch am Platz sind, weil cd nix macht. Du bist und bleibst auf Bforartists/Bforartists :/
Aber da muss es doch einen Weg geben. Du verwendest doch auch eine externe Lib wenn ich dein Actions File richtig verstanden habe.
Wie xq oben schonmal erwähnt hat: Die einzelnen Steps bei Github Actions scheinen bzgl. der Pfade komplett unabhängig voneinander zu sein. Jeder Step startet wieder neu im Hauptverzeichnis deines Repos. Sprich: Wenn du in einem Step per "cd" in nen anderes Verzeichnis wechselst, hat das keine Auswirkungen auf andere Steps. Deshalb ist das so, wie auf deinem letzten Screenshot. Du machst ein "cd" und im nächsten Step startest du doch wieder im Hauptverzeichnis.
Bestimmte Action Templates bieten deshalb die Möglichkeit, ein Working Directory als Parameter mitzugeben. Du könntest mal schauen, ob das Template, was du nutzt, sowas unterstützt.
Alternativ kannst du natürlich auch nen kleines Shell-Skript schreiben und mit einchecken, was entsprechend zuerst in das richtige Verzeichnis wechselt und dann die nötigen Build-Befehle startet. Und per Action rufst du dann einfach nur das Skript auf. Dann hast du die volle Kontrolle darüber, was genau wo passiert.
Vielen Dank für die Erklärung. Das erklärt natürlich meine Probleme wenn das immer wieder ins Arbeitsverzeichnis zurückschnalzt. Ich mache mich mal bezüglich Templates schlau. Vielleicht ist so ein Rankommen.
Ohne aus Zeitgründen jetzt alles im Detail gelesen zu haben:
Kannst Du die Kommandoketten mit 'cd' etc. nicht in ein Script verpacken und dieses dann ausführen? So mache ich es für gewöhnlich bei GitHub-Actions. Spart viel Kopfzerbrechen, weil Du dann auch ein eigenes Environment hast, falls Du noch irgendwelche Parameter oder ähnliches mitführst.
Edit: Gerade gesehen, dass @VirtualLabs2000 die Skripte schon erwähnt hat, wie gesagt, großes Votum für ein solches Vorgehen.
Ansonsten finde ich es eher positiv zu sehen, wo es auf einem solchen Vanilla-System bzgl. fehlender Bibliotheken hakt. So hat man die Möglichkeit, build-Skripte zu bauen, die auf dem kleinsten gemeinsamen Nenner für die richtige Umgebung sorgen. Ohne CI wie TravisCI oder GitHub-Actions habe ich des öfteren Abhängigkeiten in build-Skripten übersehen oder vergessen sie zu erwähnen.
Auch dir danke. Bin grade am recherchieren wie das geht :)
Naja, Dependencies gehören imho eigentlich nicht ins Repo. Das sind ja Abhängigkeiten des jeweiligen Betriebssystems. Und deswegen wundert es mich schon dass es da keine Standardlösung von Github Actions für externe Libraries gibt.
Man kann fehlende Dependencies natürlich mitkompilieren. Die Jungs von Blender waren nur so freundlich die ganzen Dinger vorzukompilieren. Was schon viel Sinn macht. Wenn ich die vorkompilierten Dependencies für Windows, Linux und Mac auch noch ins Repo packen müsste hätte das Ding mal eben 15 Gb mehr. Und wenn wir alles selber kompilieren hätten wir eine sehr viel höhere Kompilierzeit. Mit tausend möglichen Fehlerquellen mehr. Das Problem hatte Blender als sie das noch über ein install_deps.sh gelöst hatten. Da hat quasi immer irgendwas geklemmt. Speziell Boost ist da ein rechter Alptraum. Das macht also imho schon sehr viel Sinn das extern zu halten. Und für uns ist da eh kein Rankommen. Wir sind in der Hinsicht abhängig von Blender.
Naja, Dependencies gehören imho eigentlich nicht ins Repo. Das sind ja Abhängigkeiten des jeweiligen Betriebssystems. Und deswegen wundert es mich schon dass es da keine Standardlösung von Github Actions für externe Libraries gibt.
Ganz einfach: Weil es keine Standardlösung für externe Libraries gibt. Die schmerzfreiste ist: Vendoring. Also einfach die Libraries selbst mitliefern und compilieren.
Jetzt hats geschnackelt. Der Hauptjob rennt jetzt durch, es kompiliert fehlerfrei durch. Wo ich noch rumclinche ist der Upload. Aber das müsste ich auch noch in den Griff kriegen :)
working directory setzen hat das Vieh nicht weiter gejuckt. Der Trick war alles in ein einziges run zu packen. Das war der Teil den ich erst nicht hinbekommen habe und von dem ich dachte dass man jeden Befehl in eine einzelne Zeile packen muss. Und dann schnalzt es ja immer wieder zur ursprünglichen Directory zurück. Ein Hochkantstrich sorgt dafür dass man auch mehrere run Befehle hintereinander abarbeiten kann.
Ah, und ich hatte vergessen ein paar wichtige Sachen vorzuinstallieren. Vanilla Ubuntu hat nicht alles an Bord was ich brauche.
So siehts jetzt grade aus. Im Moment rennt es mit dem absoluten Pfad um zu testen ob er beim upload-artifacts die bin Directory dann findet. Und dann muss ich noch schauen wo der Upload dann zu finden ist. Vielleicht gibts ja auch eine Möglichkeit da ein Archiv zu erstellen. Aber das ist nicht mehr wirklich wichtig. Wichtig war ein grünes Pass zustande zu bekommen damit man sehen kann dass das Build fehlerfrei kompiliert.
Klasse, schön, dass es geklappt hat! Wie gesagt finde ich es allein für die Übersicht der Abhängigkeiten ein gutes Gefühl zu wissen, dass alles auf einem Vanilla-System am Ende baut.
name: C/C++ CI
on:
pull_request:
branches: [ master ]
jobs:
build:
steps:
- name: make
run: |
mkdir ~/bforartistsrepo
cd ~/bforartistsrepo
git clone https://github.com/Bforartists/Bforartists
Das bedeutet, dass auch bei Pull Requests dass CI github master baut, und NICHT die Changes aus dem Pull Request. Du solltest definitiv die offizielle checkout action nehmen, denn diese nimmt auch tatsächlich den commit, für den das CI angestoßen wurde
War mal MasterQ32, findet den Namen aber mittlerweile ziemlich albern…
Verstehe. Das zieht mir dann quasi den Stand vom Master vor dem Merge. Mit der offiziellen checkout action geht es leider nicht. Da habe ich ja dann das Pfadproblem weil das dann eben nicht in einem Rutsch zu machen ist.
Dass es nur den Master kompiliert ist aber durchaus gewollt. Das war der Plan. Alles gut. Vielleicht nehme ich das mit dem Pull Request auch wieder raus. Im Moment teste ich einen cron :)
Verstehe. Das zieht mir dann quasi den Stand vom Master vor dem Merge. Mit der offiziellen checkout action geht es leider nicht. Da habe ich ja dann das Pfadproblem weil das dann eben nicht in einem Rutsch zu machen ist.
Ich habe dir oben die Doku schon verlinkt, wo du den Pfad für den Checkout einstellen kannst.
War mal MasterQ32, findet den Namen aber mittlerweile ziemlich albern…
