Hi Niklas, danke für den Hinweis mit dem main branch und das Angebot zu debuggen. Ich fürchte, dass es noch ein anderes Problem ist:
meine gitlab-ci.yml befindet sich nicht im main branch, sondern in einem branch „mirroring-from-github“, den ich separat angelegt habe
einen main branch gab es tatsächlich bis vorhin (nämlich den automatisch erzeugten mit der default readme). Ich habe nun einen Branch „main-backup“ angelegt, den (temporär) zum default branch gemacht und den main branch gelöscht. Leider tritt der Fehler immer noch auf.
Ende 2023 hatte ich in diesem Repo einen MR gestellt, der unter anderem auch das Problem mit der Rolle „maintainer“ adressierte. Leider wurde er nie gemergt.
Die Open-Source-Community bzw. mindestens das Managment derselben funktioniert also offensichtlich nicht.
Stattdessen scheint es mir so zu sein, dass erneut viele Ressourcen in diese Komponente gesteckt werden, die
ist.
Ich erneure meine Frage vom April 2022: Warum wird nicht einfach die Enterprise-Edition eingesetzt? Dann kann man pull-mirroring mit einem Klick aktivieren!
An den Kosten kann es nicht liegen (die jetzigen Bastellösungen sind vmtl. schon teurer für die öffentliche Hand gewessen als 5 Jahre Enterprise-Lizenz) – und auch aus strategischen Gründen wäre es sinnvoll zu sagen, dass Open-Source auch finanziert werden muss, d.h. das Geschäftsmodell von gitlab zu unterstützen.
Naja. OpenCode bleibt eben eine IT-Infrastruktur der deutschen Verwaltung …
das ist eine gute Frage, die uns auch schon häufiger gestellt worden. Die Frage, warum openCode nicht die Enterprise-Version von GitLab nutzt haben wir deshalb auch schon intern diskutiert.
Einer der Gründe, die derzeit gegen die Nutzung sprechen ist, dass wir uns durch die Nutzung der EE von GitLab zusätzlich von einem Anbieter abhängig machen.
Gerade aber, weil die Funktionen immer wieder angefragt wurden, gab es erste Überlegungen, ob wir die Enterprise-Version z.B. als ‚Add-On‘ zur Verfügung stellen. Dies sind aber erste Ideen und noch nicht final durchdacht.
Ich weiß, dass das keine ganz zufriedenstellende Antwort ist, aber die Frage lässt sich aktuell noch nicht endgültig beantworten. Dafür sind noch weitere Überlegungen nötig.
Auch muss man festhalten, das auch trotz der Tatsache, dass wir hierzu schon desöfteren angesprochen wurden und die Enterprise-Funktionen wirklich nützlich sind, die Unterschiede im Funktionsumfang bisher doch nicht so groß waren, dass dies viele Nutzer*innen grundsätzlich in ihrer Arbeit eingeschränkt hätte.
Ich hab das Skript in einem Fork angepasst und es funktioniert jetzt für mich.
Externe Repository werden jetzt wieder erfolgreich in ein Repo hier im Gitlab „gespiegelt“.
Dazu muss in der ci-yml nur die URL der component angepasst werden, damit sie auf den Fork zeigt: $CI_SERVER_FQDN/sh/digitalhub-sh/interne-projekte/component-test/pull-mirroring@main
Super, danke! Drücke die Daumen, dass der MR in weniger als 2 Jahren gemergt wird!
Wenn ich es richtig sehe, basiert aber das (reparierte) Skript nach wie vor auf tokens. Wie klappt denn das mit dem self-rotate, also dass man nicht manuell etwas ändern muss, wenn die tokens nach 12 Monaten ablaufen? Das ist bei mir nämlich der Fall und auf diese Frage hatte ich leider keine Antwort bekommen:
Gerne.
Ich hab nur dafür gesorgt, dass es funktioniert. Funktionserweiterungen sind keine dabei. Meine Skills als (Vibe-)Coder sind begrenzt. Im Moment bin ich froh, dass meine Projekte wieder syncen.