Die Runner-Wahl für Dependabot rutscht auf die Ebene des Repositorys
Victoria Shinder1 Min. LesezeitGitHub bietet die Runner-Konfiguration von Dependabot nun pro Repository an. Bisher ließ sie sich auf Organisationsebene festlegen; seit 29. September kann ein Repository-Administrator Runner-Typ, optionales Label und optionale Runner-Gruppe für Dependabot-Versions- und Sicherheitsupdates wählen.
Ein gelabelter Runner kann selbst gehostet sein oder einer der größeren von GitHub gehosteten Runner. Das Changelog nennt die typischen Gründe: Zugriff auf private Paket-Registries oder andere spezielle Umgebungen, die ein Standard-Runner nicht erreicht. Ohne Label nutzt Dependabot das Label dependabot; mit Standard GitHub runner bleibt es bei der gehosteten Standardumgebung.
Die Einstellung liegt in den Advanced-Security-Einstellungen des Repositorys unter Dependency scanning, wo „Dependabot version updates“ jetzt eine Option Runner type hat. Sie gilt für private und interne Repositorys auf github.com. Für öffentliche Repositorys sind die Optionen ausgeblendet, auf GitHub Enterprise Server gibt es sie nicht. GitHub weist zudem darauf hin, dass Sicherheitskonfigurationen Dependabot-Runner-Einstellungen noch nicht durchsetzen, eine Organisation kann darüber also derzeit keine einheitliche Wahl vorschreiben.
Warum das wichtig ist
Dependabot-Updates scheitern still, wenn der Job die Registry einer privaten Abhängigkeit nicht erreicht, und die übliche Lösung war, der ganzen Organisation dieselbe Runner-Einrichtung zu geben. Die Steuerung pro Repository erlaubt, nur die betroffenen Repositorys zu einem Runner im eigenen Netz zu leiten, ohne alle anderen zu ändern, um den Preis einer weiteren Einstellung, die Sicherheitskonfigurationen noch nicht überwachen.