Ich habe deutlich mehr Zeit dafür gebraucht, als ich gedacht hätte (und die benötigten Access-Tokens sind nur ein Jahr gültig, man muss also immer wieder aktiv werden) und auch deutlich mehr Zeit als einfach nur einen Häkchen zu setzen. Ich kann das Argument sehr gut nachvollziehen, dass keine Gitlab-Enterprise-Edition genutzt wird, weil die nicht open-source ist. Die Version, die genutzt wird, ist ja allerdings open source: Ich würde also dringend raten, dass dieses Feature durch das ZenDis nachprogrammiert wird (denn so kompliziert ist es ja nun wirklich nicht, würde aber viel Zeit bei anderen Dienststellen sparen).
Im Datenlabor BMZ würden wir uns auch sehr über dieses Feature freuen!
Es wird keine Enterprise-Edition von gitlab eingesetzt, weil die nicht 100% „open source“ ist. Geld ist nicht das Problem.
Das ist für mich nicht nachvollziehbar. Es gibt ja leider keine festen Regeln zur open source Vergabe und es wird jede Menge closed source Software vergeben (https://mdb.anke.domscheit-berg.de/2024/03/pm-bremse-fuer-opensource-zendis/). Hier gäbe es einmal die Möglichkeit, closed source Software zu kaufen, die extrem nützlich für open source ist, es wäre sehr cool, wenn das auch genutzt würde!
Auch wenn dieser Thread jetzt schon einige Jahre alt ist, an dieser Stelle ein kleines Update zum Stand der Nutzung einer Enterprise Edition:
Open CoDE wird auch in Zukunft die Community Version von GitLab nutzen. Dies begründet sich alleine durch die Unabhängigkeit von propriäteren Lizenzen.
Aufgrund der häufigen Nachfrage nach Funktionen der Enterprise Edition, erwägt Open CoDE derzeitig allerdings die Einrichtung einer weiteren GitLab-Instanz in der Enterprise Edition. Weitere Informationen hierzu werden in Kürze folgen.
Eine gute Entscheidung! Es gibt auch große Instanzen von GitLab, die komplett auf die Community Version setzen, z.B. Siemens. Bei Investitionen in die Community Version ist sichergestellt, dass alle dauerhaft von diesen Verbesserungen profitieren.
Genau. In Konsequenz müssen Anpassungsbedarfe an der Community Version, die hier im Umfeld der öffentlichen Verwaltung umgesetzt werden auch Upstream zurückfließen.
Danke, für das Update und v.a. auch danke, dass es an dieser Stelle kommt (woanders würde ich es vermutlich gar nicht mitbekommen). Ich bin gespannt auf die Infos zur Enterprise-Edition.
Wo werden denn Verbesserungswünsche für die Community-Version gesammelt, die dann idealerweise an upstream zurückfließen?
Hi @terstiege . Cool, dass du es hingekriegt hast.
Wir können darauf aufbauen und GitLab CI/CD Components nutzen, in denen bestimmte CI-Jobs gekapselt und von vielen Projekten wiederverwendet werden können. Beispielsweise könnte man die gewünschte Repo-Pull-Mirroring Funktion als eine Job-Definition mit Eingabeparametern nachbauen und für alle OpenCode Projekte anbieten. Soweit ich das sehe, ist der CI/CD Component-Catalog auch schon auf OpenCode ausgerollt .
Ja. Dieser Mechanismus besteht weiterhin und würde ich aus Sicherheitsgründen auch so empfehlen.
Um dieses Problem zu lösen könnte man einen CI-Job (oder eine CI/CD Component) definieren, die das Personal Access Token regelmäßig austauscht / rotiert, bspw. täglich oder wöchentlich.
Alternativ könnte man die Rotation der Tokens auch in GitLab selbst als Open Source Contribution implementieren. Das GitLab Team würde Open Source Unterstützung in diesem Bereich begrüßen, siehe Add a rotate_self scope for token (#430748) · Issues · GitLab.org / GitLab · GitLab . Sobald es in der GitLab Community Edition enthalten ist und auf OpenCode ausgerollt ist, dann bräuchte man auch kein speziellen CI-Job für die Rotation der Tokens
Ah, danke für den Link. Da scheint ja wieder Fahrt in das Ticket gekommen zu sein.
Ich glaube, ich würde unsere Tokens dann einmalig manuell aktualisieren und dann darauf setzen, dass innerhalb des nächsten Jahres das Feature implementiert ist.
@terstiege Ja, du hast recht. Da ist wieder etwas Bewegung im Issue. Mal gucken wie es weitergeht. Als GitLab Open Source Contributor habe ich die Erfahrung gemacht, dass es häufig länger dauert als man denkt.
Nichtsdestotrotz ist es grandios, dass es überhaupt möglich ist, die GitLab Plattform nach den eigenen Anforderungen mitzugestalten – Open Source macht es möglich
Hallo Zusammen, ich habe nun die Zeit gefunden, um ein Testprojekt aufzusetzen, das eine CI/CD-Component nutzt, um das GitHub-Repo „mindwendel“ täglich zu spiegeln (Pull-Mirroring ). Dafür bin ich wie folgt vorgegangen:
Leeres Projekt auf OpenCode erstellen oder gewünschtes GitHub-Projekt importieren
Im neuen Projekt einem separaten Branch erstellen, bspw. ci-job-pull-mirror-remote-repo damit dieser Branch nicht mit den
Aktuell kann die neue CI/CD-Component „Pull Mirroring TESTING“ ein externes Git-Repo nur in das OpenCode-Projekt spiegeln, in dem die Component als CI-Job läuft. Das geht besser und man könnte die CI/CD-Component auch erweitern, damit die Component in ein beliebiges OpenCode-Projekt hineinspiegeln kann.
Hinweis: Die neue CI/CD-Component „Pull Mirroring TESTING“ ist zunächst nur als Test oder Proof-Of-Concept gedacht. Es zeigt, dass die einfache Einrichtung des Pull-Mirrorings mittels einer CI/CD-Component auf OpenCode möglich ist. Mit mehr Zeit und Tests wird die CI/CD-Component ausgereifter.
Leider laufen die Tokens nach 12 Monaten aus und man muss sie manuell erneuern.
Inzwischen scheint das self-rotate aber fertig implementiert zu sein. Ich sehe jetzt auch einen Button dafür bei den jeweiligen Repositories. Nur: Die Meldung beim rotate ist:
This action cannot be undone. Any tools that rely on this access token will stop working.
Ich vermute, dass ich dann auch doch wieder händisch die Tokens in den Umgebungsvariablen des pull-Repositories aktualisieren muss. Es ist also nahezu nichts gewonnen.
Im selfrotate-issue gibt es auch ein Skript, um dieses rotate zu automatisieren und das neue Token wegzuschreiben.
Weiß jemand, wie ich das so hinkriege, dass das token tatsächlich versteckt bleibt (also nicht als Datei im repo liegt)?
Im Prinzip müsste das Skript statt auf eine Datei zuzugreifen auf die gesetzte Umgebungsvariable zugreifen, also das, was unter settings/ci_cd#js-cicd-variables-settings zu sehen ist.
(Eine entsprechende Lizenz für gitlab wäre immer noch super, dann ist nur ein Haken ohne Extra-Repos und Tokens und und und …)
Hallo Zusammen, habe im Thread viel über CI/CD gefunden, aber für den Moment würden wir gern manuell ein Repo aus Github nach Gitlab syncen bei Bedarf. Weiß jemand ob es da einen Button gibt ähnlich dem initialen „Import from Git Repo“ ?
Ich habe eine offizielle Anleitung „Projekte spiegeln“ im „openCode Guide“ gefunden: Projekte spiegeln - openCode Guide
Allerdings scheitere ich immer wieder an kleinen und größeren Fehlern. Die dort beschriebene Pipeline sieht wie die aus, die @oc000022602491 hier verlinkt hat. Liest du hier noch mit?
Ich versuche anhand der Anleitung Pull Mirroring von einem GitHub Repo nach opencode umzusetzen. Hier mal die Probleme, auf die ich gestoßen bin:
Für das Erstellen von Project access tokens muss man die Rolle „Maintainer“ haben. (siehe Permissions and roles | GitLab Docs). Ich wurde nur als „Developer“ ins Projekt eingeladen (was ja auch erstmal sinnvoll ist). In der Anleitung wird diese Voraussetzung nicht genannt.
Das Code Snippet für die gitlab-ci.yml hat einen Syntaxfehler. Wenn man das so ausführt wie es dort steht, kommt die Fehlermeldung
" gitlab.opencode.de/pull-mirroring/component/pull-mirroring@1.0.1: target_url input: required value has not been provided"
Die Lösung: inputs gehört zu dem Abschnitt, der weiter oben anfängt, muss also auf die gleiche Höhe wie components eingerückt werden, die Unterpunkte von inputs entsprechend noch weiter.
Soweit zu den Problemen, für die ich selber schon Lösungen gefunden habe. Jetzt läuft die Pipeline vermeintlich erfolgreich durch (inkl grünem Häkchen). Allerdings ist kein Code im Projekt angekommen und im Log steht folgendes:
remote: GitLab: You cannot create a branch with an invalid name.
To [project url]
! [remote rejected] upstream/main → main (pre-receive hook declined)
! [remote rejected] upstream/HEAD → HEAD (pre-receive hook declined)
! [remote rejected] upstream/feature/[feature-branch-name] → feature/[feature-branch-name] (pre-receive hook declined)
error: failed to push some refs to ‚[project url]‘
WARNING: after_script failed, but job will continue unaffected: command terminated with exit code 1
Cleaning up project directory and file based variables00:01
Job succeeded
Das ist aus zwei Gründen ärgerlich.
natürlich, weil es nicht funktioniert und ich noch nicht herausgefunden habe, was das Problem ist.
unsere branch names enthalten nicht offensichtlich invalide Zeichen
ich habe sogar die branch protection vom main branch entfernt
weil die Pipeline nicht an diesen Fehlern scheitert, obwohl ja der Zweck der Pipeline nicht erfüllt werden konnte. Jetzt wo das Projekt noch leer ist, ist mir das sofort aufgefallen. Später würde das bestimmt übersehen werden, weil ja ohne Blick ins Log die Pipeline vermeintlich erfolgreich lief.
PS: ich bin heute noch auf eine weitere CI Component gestoßen, die wohl gerade in Entwicklung ist: https://gitlab.opencode.de/pull-mirroring/pull-manager. Der scheint dafür gedacht zu sein, die Verwaltung von Mirrors aus den eigentlichen Projekten herauszulösen, was ich aber eh nicht ausprobieren kann, weil ich als Externer keine Repos anlegen kann.
(Eigentlich war ich nur auf der Suche nach dem source code von gitlab.opencode.de/pull-mirroring/component/pull-mirroring@1.0.1Pull-Mirroring / component · GitLab)
vielleicht kann @oc00004673237 was dazu sagen, der ja an beidem mitentwickelt
ich kann deinen Ärger sehr gut nachvollziehen. Der Setup ist leider aus verschiedenen Gründen sehr Fehleranfällig und daher arbeite ich gerade daran, die Komponente zu vereinfachen.
Gerardo hat u.a. angestoßen, dass die Komponente am besten in einem eigenen Repo verwaltet wird, damit die .gitlab-ci.yml nicht auf einem separaten Branch erstellt werden muss.
Genau hier kann auch dein Problem zu suchen sein: Das Problem ist nämlich, wenn man die Komponente einfach in die .gitlab-ci.yml auf dem main Brainch einbindet, dass git sich weigert das Repo zu spiegen, da der Branch main nicht leer ist.
Kannst du mir aber am besten nochmal dein Repo verlinken, damit ich das besser debuggen kann? Gerade muss ich nämlich anhand deiner Fehlerbeschreibung rätseln, was wohl dein Problem sein könnte.
Die Einrückungsfehler, die du erwähnt hast, sind jedenfalls jetzt behoben und jetzt sollten keine Probleme mehr bei der Nutzung Vorlage auftreten.
Hallo Zusammen, ich habe nun die Zeit gefunden, um 
). Dafür bin ich wie folgt vorgegangen: