oss attribution builder

OSS Attribution Builder

OSS Attribution Builder ist eine Website, auf der Teams zu Attributionsdokumenten für Softwareprodukte erstellt werden. Ein Attributionsdokument ist eine Textdatei, eine Webseite oder einen Bildschirm in nahezu jeder Softwareanwendung, die die verwendeten Softwarekomponenten und deren Lizenzen auflistet. Sie sind oft in den Überläufen und werden manchmal als "Open Source -Notizen", "Credits" oder eines anderen ähnlichen Jargons bezeichnet.

Screenshot

QuickStart

1. Docker installieren
2. Klonen Sie dieses Repository
3. Führen Sie docker-compose up
4. Besuchen Sie http: // localhost: 8000/
   • Die Demo verwendet HTTP Basic Auth. Geben Sie einen beliebigen Benutzernamen und Passwort ein. Verwenden Sie admin , um die Administratorfunktionen zu testen.

Verwenden der Website

Siehe Dokumentation:

• Für Benutzer
• Für Administratoren

Einschränkungen

Der Attribution Builder war ursprünglich ein Amazon-Internet-Tool. Einige Teile mussten entfernt werden, um dies zu einem vernünftigen Open -Source -Projekt zu machen. Daher gibt es einige Warzen:

• Projekte haben Kontaktlisten, aber im Moment unterstützt die Benutzeroberfläche nur einen Kontakt (der rechtliche Kontakt).

Diese werden alle rechtzeitig behoben, aber seien Sie sich bewusst, dass einige Dinge für eine Weile seltsam sein könnten.

Benutzerdefinierte Bereitstellung

Wenn Sie bereit sind, den Attribution Builder in Ihre eigene Umgebung zu integrieren, müssen einige Dinge eingerichtet werden:

Konfiguration

Öffnen Sie config/default.js und stupsen Sie herum. Diese Konfiguration startet, wenn Sie docker-compose ausführen oder die Anwendung auf andere Weise starten.

Lizenzen

Der Attribution Builder unterstützt zwei Arten von Lizenzdefinitionen:

• SPDX -Identifikatoren
• "Bekannte" Lizenztexte und Tags

SPDX-Identifikatoren werden nur zum Vorbereiten des Lizenzauswahl verwendet, haben jedoch nicht (derzeit) Texte. Die nützlichere Lizenzart ist eine "bekannte" Lizenz, in der Sie (der Administrator) den Text der Lizenz und alle Tags, die Sie bewerben möchten, den Text liefern.

Informationen zum Hinzufügen Ihrer eigenen "bekannten" Lizenzen finden Sie in der Lizenz Readme. Es gibt zwei vorhandene Lizenzen in demselben Verzeichnis, das Sie als Beispiele betrachten können.

Tags

Mit Tags können Sie einer Lizenz beliebige Validierungsregeln hinzufügen. Sie können nützlich sein für:

• Die Überprüfung einer Lizenz wird richtig verwendet (z. B. LGPL und wie ein Paket verknüpft wurde)
• Annotieren Sie eine bestimmte Lizenz als Follow -up, wenn Ihr Unternehmen über spezielle Prozesse verfügt
• Bereitstellung von Anleitungen zur Zuordnung für Lizenzen mit vielen Varianten
• Ändern der Art und Weise, wie eine Lizenz in einem Attributionsdokument angezeigt wird

Informationen darüber, was Tags tun können und wie Sie Ihre eigenen erstellen können, finden Sie in den Tags Readme.

Erweiterungen

Der Attribution Builder bietet eine Form von Erweiterungen, mit denen Sie das Verhalten und das Erscheinungsbild des Kunden auf dem Kunden vor Ort ändern können, ohne dass sie Interna patchen müssen. Dies kann Upgrades leichter ausmachen.

Einzelheiten finden Sie in den Erweiterungen Readme.

Authentifizierungsmodul

Der Attribution Builder unterstützt es, den Zugriff auf bestimmte Personen oder Gruppen mithilfe von Projekt -ACLs einzuschränken. Diese können auch zur Verwaltung und zur "Überprüfung" von Paketen verwendet werden (Einzelheiten dazu in einem späteren Abschnitt). Die Standardimplementierung nullauth ist in den meisten Umgebungen nicht sehr nützlich. Sie möchten Ihre eigenen schreiben, wenn Sie allgemeiner starten.

Implementierungsdetails finden Sie in der Basisauth -Schnittstelle.

Läuft

Um den Server zu starten, sollten Sie build/server/localserver.js nach dem Erstellen mit npm run build ausführen. Es gibt einige Umgebungsvariablen, die Sie beim Ausführen wahrscheinlich festlegen möchten:

• NODE_ENV sollte höchstwahrscheinlich auf production eingestellt werden
• CONFIG_NAME sollte auf den Basisname (keine Erweiterung) Ihrer oben erstellten Konfigurationsdatei eingestellt werden. Der Standard ist "Standard".

Der Server wird nur in HTTP ausgeführt. Sie möchten wahrscheinlich einen dünnen HTTPS -Webserver oder Proxy vor sich stellen.

Beitragen

Informationen zu Informationen sehen.

Entwicklung

npm install und dann npm run dev werden Sie für die lokale Entwicklung in den Höhe von Boden bringen. Dies startet einen Docker -Container für PostgreSQL, verwendet jedoch eine lokale Kopie von TSC, Webpack, Knoten usw., sodass Sie schnell iterieren können.

Sobald die Dinge begonnen haben, können Sie http://0.0.0.0:2425/webpack-dev-server/ öffnen. Dies wird automatisch die Änderungen der Browser-Änderungen neu laden, und das Backend startet auch automatisch die serverseitigen Änderungen neu.

Handliche Umgebungsvariablen:

• NODE_ENV : Wenn nicht festgelegt oder development , erhalten Sie vollständige Quellkarten und Debug -Protokolle
• DEBUG_SQL : Wenn Sie (auf irgendetwas) gesetzt sind, werden SQL -Abfragen zum Terminal angezeigt

Testen

npm test wird in Einheits -Tests ausgeführt. Diese sind in erster Linie auf Server konzentriert.

npm run test-ui führt Selenium-Tests durch. Sie können die Umgebungsvariable SELENIUM_DRIVER festlegen, wenn Sie einen benutzerdefinierten Treiber wünschen - standardmäßig wird versucht, Chrome zu verwenden, und wenn dies nicht verfügbar ist, fällt es auf Phantomjs zurück.

Beim Debuggen von UI-Tests kann es einfacher sein, standalone-chrome in docker-compose.selenium.yml in standalone-chrome-debug zu ändern und dann über VNC (Port 5900, Passwort "Secret") mit dem Container herzustellen. Führen Sie den Container und Ihre Tests getrennt aus:

• docker-compose -f docker-compose.selenium.yml up --build
• tsc && jasmine --stop-on-failure=true 'build/selenium/*.spec.js'

Tests, die scheinbar ohne Grund versagen? driver.sleep nicht funktionieren? Stellen Sie sicher, dass Ihre Jasmin -Zeitüberschreitung in Ihrem Test hoch genug ist.