Sci Simple

New Science Research Articles Everyday

# Computerwissenschaften # Logik in der Informatik

Isabelle bekommt einen neuen Build-Manager

Die Isabelle-Plattform verbessert die Effizienz mit ihrem neuen benutzerdefinierten Build-Manager.

Fabian Huch

― 6 min Lesedauer


Isabelles Bau-Revolution Isabelles Bau-Revolution Bau-Effizienz. Ein grosses Upgrade für verbesserte
Inhaltsverzeichnis

Isabelle ist ein mächtiges Tool in der Welt der Mathematik und Informatik. Es hilft Forschern und Entwicklern, die Richtigkeit von Beweisen zu überprüfen. Um alles am Laufen zu halten, brauchte die Isabelle-Plattform einen Build-Manager – ein System, das verschiedene Komponenten zusammensetzt, damit sie reibungslos zusammenarbeiten. Man kann sich das wie einen Koch vorstellen, der ein mehrgängiges Menü zubereitet und sicherstellt, dass alle Gerichte zur richtigen Zeit und Temperatur fertig werden.

Die alte Methode: Jenkins Build-Server

Lange Zeit hat Isabelle auf Jenkins als Build-Manager gesetzt. Jenkins ist ein beliebtes Tool für kontinuierliche Integration, was bedeutet, dass es hilft, den Prozess des Testens und Bauens von Software zu automatisieren. Aber wie ein Koch, der seine Lieblingsspachtel nicht findet, hatte Jenkins einige Mängel. Es hatte Schwierigkeiten, von Nutzern eingereichte Builds effektiv zu handhaben, was bedeutete, dass es langsam und manchmal unzuverlässig war. Jobs schlugen unerwartet fehl, und das ganze System wurde langsamer, was die Nutzer frustriert hat.

Der Bedarf an Veränderung

Mit der zunehmenden Komplexität der Isabelle-Plattform war es, als würde man versuchen, einen Sportwagen mit einem Platten zu fahren. Die Community erkannte, dass sie einen neuen Ansatz brauchten. Sie wollten etwas, das die speziellen Anforderungen von Isabelle ohne die Kopfschmerzen des alternden Jenkins-Systems bewältigen konnte. Also beschlossen sie, einen neuen Build-Manager mit Isabelles eigenem Programmierumfeld zu entwickeln.

Einführung des neuen Isabelle Build-Managers

Der neue Isabelle Build-Manager ist komplett innerhalb der Isabelle/Scala-Programmierumgebung gebaut. Das war ein grosser Schritt. Anstatt sich auf ein externes Tool zu verlassen, haben sie ein System geschaffen, das die inneren Abläufe von Isabelle versteht.

Die Struktur des Build-Managers

Denk an den neuen Build-Manager wie an ein gut koordiniertes Team von Arbeitern in einer Fabrik. Jeder Arbeiter hat eine spezielle Aufgabe:

  1. Poller: Dieser Arbeiter hört auf Updates. Wenn sich im Isabelle-Repository oder bei zusätzlichen Komponenten etwas ändert, stellt dieser Arbeiter Aufgaben für die notwendigen Jobs zusammen.

  2. Timer: Der Timer setzt Aufgaben, die zu bestimmten Zeiten laufen, wie ein Bäcker, der einen Timer für einen Kuchen im Ofen stellt, anstatt jedes Mal zu warten, wenn jemand die Bäckerei betritt.

  3. Runner: Dieser Arbeiter prüft, welche Aufgaben bereit sind zu starten. Wenn er eine bereitstehende Aufgabe findet, startet er diesen Job. Wenn ein Job zu lange dauert und Zeitüberschreitung hat, kann der Runner ihn unterbrechen, genau wie ein Lehrer, der eingreift, wenn ein Schüler zu lange für einen Test braucht.

  4. Web-Server: Denk daran wie an den Manager, der alle informiert. Er stellt Webseiten bereit, die den aktuellen Zustand der Builds und Logs anzeigen, damit die Nutzer sehen können, was gerade passiert.

Einen Build ausführen

Wenn es an der Zeit ist, einen Build auszuführen, ist der Prozess besser organisiert als je zuvor. Der Build-Manager erhält Aufgaben, die detailliert beschreiben, was gebaut werden muss. Dann sorgt er für ein wenig Ordnung, indem er eine eigenständige Kopie von Isabelle und seinen erforderlichen Komponenten erstellt. Das ist wie das Einrichten eines sauberen Arbeitsplatzes bevor man mit einem Projekt anfängt.

Der eigentliche Build läuft in vier einfachen Schritten:

  1. Der Runner sammelt alles, was für den Build benötigt wird, wie Einkaufen von Zutaten bevor man kocht.
  2. Er erstellt die Umgebung, die für den Build benötigt wird, und bringt alles an seinen Platz, wie das Bereitstellen von Töpfen und Pfannen.
  3. Der Build wird remote ausgeführt, überwacht über ein Terminal, was den Nutzern ermöglicht, Echtzeit-Updates zu sehen, wie beim Zuschauen einer Kochshow, wo man alles live sehen kann.
  4. Nach Abschluss des Builds werden die Ergebnisse aufgezeichnet und alle notwendigen Aufräumarbeiten erledigt.

Dynamische Web-Präsenz

Der neue Build-Manager bietet eine benutzerfreundliche Web-Oberfläche. Das ist wie ein Bedienfeld, auf dem man alle seine Geräte auf einen Blick sehen kann. Nutzer können den Status der Builds überprüfen, sehen, welche gerade laufen, und sie sogar abbrechen, wenn nötig.

Durch die Verwendung von statischem HTML und ein wenig JavaScript bietet der Webserver eine reibungslose Erfahrung, ohne dass Nutzer komplizierte Software herunterladen müssen.

Builds einreichen

Nutzer können ihre Builds ähnlich einreichen, wie man eine Bestellung in einem Restaurant aufgibt. Sie müssen sich einfach über SSH mit dem Server verbinden, was wie einen Anruf im Restaurant und das Aufgeben der Bestellung ist. Das System nutzt isabelle.Sync, um sicherzustellen, dass alles auf dem neuesten Stand ist, und sobald die Aufgabe registriert ist, erhalten die Nutzer einen privaten Link, um ihre Bestellungen zu überwachen.

Systemkonfiguration: Eine einfache Einrichtung

Der Build-Manager benötigt minimale Infrastruktur. Es ist wie das Einrichten einer kleinen Küche im Vergleich zu einer grossen Restaurantküche. Jeder Nutzer hat ein individuelles Setup mit Präferenzen, die konfiguriert werden müssen, aber es ist nichts, was einen Abschluss in Raketentechnik erfordert.

Builds parallel ausführen

Das neue System ermöglicht auch das gleichzeitige Ausführen mehrerer Builds. Das ist wie mehrere Köche in der Küche zu haben, die an verschiedenen Gerichten arbeiten, ohne sich gegenseitig im Weg zu stehen. Während ein Koch einen Salat zubereitet, kann ein anderer ein Steak braten, was den Prozess effizienter macht.

Benutzeroberfläche: Einfachheit im Fokus

Die Benutzeroberfläche des neuen Build-Managers ist einfach gehalten. Sie ähnelt dem alten Jenkins-Layout, bietet aber ein aktualisiertes Gefühl. Nutzer können schnell einen Blick auf allgemeine Statistiken werfen, sehen, wie viele Builds derzeit laufen, und auf Build-Logs zugreifen.

Mit nur wenigen Klicks kann jeder den Status seiner Builds sehen, welche Sessions abgeschlossen sind und ob irgendetwas schiefgelaufen ist. Diese Einfachheit ist entscheidend, weil sie es den Nutzern ermöglicht, sich auf ihre Arbeit zu konzentrieren, anstatt herauszufinden, wie man sich im System zurechtfindet.

Fazit: Ein Neuanfang

Der neue Build-Manager stellt eine erhebliche Verbesserung gegenüber dem alten Jenkins-System dar. Er strafft den Build-Prozess und macht es den Nutzern viel einfacher, ihre Aufgaben zu erledigen. Während sich die Plattform weiterentwickelt, können neue Funktionen hinzugefügt werden, um noch mehr Fähigkeiten zu unterstützen.

In Zukunft hat der Build-Manager das Ziel, die Forschung reproduzierbarer zu machen und den Nutzern zu helfen, ihre Daten effektiv zu verwalten. Dynamisches Hoch- und Runterskalieren von Ressourcen könnte auf dem Horizont erscheinen, um eine optimale Nutzung der Hardware zu gewährleisten, während das System reibungslos läuft.

Mit dem neuen Build-Manager hat die Isabelle-Community einen riesigen Schritt in Richtung eines organisierten und effizienten Workflows gemacht. Wer hätte gedacht, dass Bauen so viel Spass machen könnte?

Originalquelle

Titel: Isabelle as Systems Platform: Managing Automated and Quasi-interactive Builds

Zusammenfassung: Interactive theorem provers are complex systems that require sophisticated platform efforts - and hence systems programming environments - to manage effectively. The Isabelle platform exemplifies this with its Isabelle/Scala systems programming environment, which has proven to be very successful. In contrast, much of the project infrastructure has relied on external tooling in the past, despite shortcomings. For continuous integration, the previous system employed a Jenkins server, which did not adequately support user-submitted Isabelle builds and faced issues with reliability and performance. In this work, we present our design and implementation of a new Isabelle build manager that replaces the old continuous integration system, fully implemented within Isabelle/Scala. We illustrate how our implementation utilizes different modules of the environment, which supported all aspects of the build manager well.

Autoren: Fabian Huch

Letzte Aktualisierung: 2024-12-17 00:00:00

Sprache: English

Quell-URL: https://arxiv.org/abs/2412.13083

Quell-PDF: https://arxiv.org/pdf/2412.13083

Lizenz: https://creativecommons.org/licenses/by/4.0/

Änderungen: Diese Zusammenfassung wurde mit Unterstützung von AI erstellt und kann Ungenauigkeiten enthalten. Genaue Informationen entnehmen Sie bitte den hier verlinkten Originaldokumenten.

Vielen Dank an arxiv für die Nutzung seiner Open-Access-Interoperabilität.

Ähnliche Artikel