OSS Attribution Builder est un site Web qui aide les équipes à créer des documents d'attribution pour les produits logiciels. Un document d'attribution est un fichier texte, une page Web ou un écran dans à peu près toutes les applications logicielles qui répertorient les composants logiciels utilisés et leurs licences. Ils sont souvent dans les écrans à propos et sont parfois étiquetés "avis open source", "crédits" ou autre jargon similaire.
Capture d'écran
docker-compose upadmin pour tester les fonctionnalités administratives. Voir documentation:
Le constructeur d'attribution était à l'origine un outil Amazon Internet. Certaines parties ont dû être supprimées pour en faire un projet open source raisonnable. En tant que tels, il y a des verrues:
Tout cela sera corrigé dans le temps, mais sachez que certaines choses pourraient être bizarres pendant un certain temps.
Si vous êtes prêt à intégrer le constructeur d'attribution dans votre propre environnement, il y a certaines choses à mettre en place:
Ouvrez Config / Default.js et perdez. Cette configuration est lancée lorsque vous exécutez docker-compose ou lancez l'application.
Le constructeur d'attribution prend en charge deux types de définitions de licence:
Les identifiants SPDX sont simplement utilisés pour pré-remplir le sélecteur de licence, mais n'ont pas (actuellement) des textes. Le type de licence le plus utile est une licence "connue", où vous (l'administrateur) fournissez le texte de la licence et toutes les balises que vous souhaitez appliquer.
Pour plus d'informations sur l'ajout de vos propres licences "connues", consultez la licence Readme. Il existe deux licences existantes dans le même répertoire que vous pouvez consulter pour des exemples.
Les balises vous permettent d'ajouter des règles de validation arbitraires à une licence. Ils peuvent être utiles pour:
Pour plus d'informations sur ce que les balises peuvent faire et comment créer la vôtre, consultez les balises Readme.
Le constructeur d'attribution offre une forme d'extensions qui vous permettent de modifier le comportement et l'apparence du site côté client, sans avoir besoin de corriger les internes. Cela peut faciliter les mises à niveau.
Voir les extensions Readme pour plus de détails.
Le constructeur d'attribution prend en charge la possibilité de restreindre l'accès à certaines personnes ou groupes à l'aide du projet ACLS. Ceux-ci peuvent également être utilisés pour l'administration et pour «vérifier» des packages (détails sur celui-ci dans une section ultérieure). L'implémentation par défaut nullauth n'est pas très utile pour la plupart des environnements; Vous voudrez écrire le vôtre lors du lancement plus largement.
Voir l'interface de base Auth pour les détails de l'implémentation.
Pour démarrer le serveur, vous devez exécuter build/server/localserver.js après la construction avec npm run build . Il existe des variables d'environnement que vous voudrez probablement définir en cours d'exécution:
NODE_ENV devrait très probablement être mis en productionCONFIG_NAME doit être défini sur le nom de base (pas d'extension) de votre fichier de configuration que vous avez créé ci-dessus. La valeur par défaut est "par défaut".Le serveur s'exécute uniquement dans HTTP. Vous voulez probablement mettre un mince serveur Web HTTPS ou proxy devant lui.
Voir contribuer à des informations.
npm install , puis npm run dev vous fera décoller pour le développement local. Cela démarrera un conteneur Docker pour PostgreSQL, mais utilisera une copie locale de TSC, WebPack, Node, etc. afin que vous puissiez itérer rapidement.
Une fois que les choses ont commencé, vous pouvez ouvrir http://0.0.0.0:2425/webpack-dev-server/. Cela se rechargera automatiquement sur les modifications du navigateur, et le backend redémarrera également automatiquement sur les modifications côté serveur.
Variables d'environnement pratique:
NODE_ENV : Lorsque vous vous êtes non-set ou development , vous obtiendrez des cartes source complètes et des journaux de débogageDEBUG_SQL : Lorsqu'il est défini (sur n'importe quoi), cela affichera les requêtes SQL sur le terminal lors de leur exécution npm test exécutera des tests unitaires. Ce sont principalement axés sur le serveur.
npm run test-ui effectuera des tests de sélénium. Vous pouvez définir la variable d'environnement SELENIUM_DRIVER si vous voulez un pilote personnalisé - par défaut, il essaiera d'utiliser Chrome, et si cela n'est pas disponible, il retombera à Phantomjs.
Lors du débogage des tests d'interface utilisateur, il peut être plus facile de modifier standalone-chrome en standalone-chrome-debug dans docker-compose.selenium.yml , puis se connecter au conteneur via VNC (port 5900, mot de passe "secret"). Exécutez le conteneur et vos tests séparément:
docker-compose -f docker-compose.selenium.yml up --buildtsc && jasmine --stop-on-failure=true 'build/selenium/*.spec.js' Les tests échouant pour apparemment aucune raison? driver.sleep ne fonctionne pas? Assurez-vous que votre délai de jasmin sur votre test est suffisamment élevé.