oss attribution builder
0.9.0
OSS Attribution Builder es un sitio web que ayuda a los equipos a crear documentos de atribución para productos de software. Un documento de atribución es un archivo de texto, página web o pantalla en casi todas las aplicaciones de software que enumeran los componentes de software utilizados y sus licencias. A menudo se encuentran en las pantallas, y a veces se etiquetan como "avisos de código abierto", "créditos" u otra jerga similar.
Captura de pantalla
docker-compose upadmin para probar la funcionalidad de administración. Ver documentación:
El constructor de atribuciones era originalmente una herramienta de Amazon-Internal. Algunas porciones tuvieron que eliminarse para hacer de este un proyecto de código abierto sensato. Como tal, hay algunas verrugas:
Todo esto se solucionará a tiempo, pero tenga en cuenta que algunas cosas pueden ser extrañas por un tiempo.
Si está listo para integrar el constructor de atribuciones en su propio entorno, hay algunas cosas para configurar:
Abre config/default.js y hurgando. Esta configuración se inicia cuando ejecuta docker-compose o inicia la aplicación.
El constructor de atribuciones tiene soporte para dos tipos de definiciones de licencia:
Los identificadores SPDX solo se usan para el relleno previamente el selector de licencias, pero no tienen (actualmente) textos. El tipo de licencia más útil es una licencia "conocida", donde usted (el administrador) proporciona el texto de la licencia y cualquier etiqueta que desee aplicar.
Para obtener información sobre cómo agregar sus propias licencias "conocidas", consulte el ReadMe de la licencia. Hay dos licencias existentes en el mismo directorio que puede ver para ejemplos.
Las etiquetas le permiten agregar reglas de validación arbitraria a una licencia. Pueden ser útiles para:
Para obtener información sobre lo que pueden hacer las etiquetas y cómo crear la suya, consulte las etiquetas ReadMe.
El constructor de atribuciones ofrece alguna forma de extensiones que le permiten alterar el comportamiento y la apariencia del sitio del lado del cliente, sin necesidad de parchear las partes internas. Esto puede facilitar las actualizaciones.
Vea el ReadMe de extensiones para más detalles.
El constructor de atribuciones admite poder restringir el acceso a ciertas personas o grupos utilizando ACL del proyecto. Estos también se pueden usar para la administración y para "verificar" los paquetes (detalles sobre eso en una sección posterior). El nullauth de implementación predeterminado no es muy útil para la mayoría de los entornos; Querrá escribir el suyo cuando se lance más ampliamente.
Consulte la interfaz base de autenticación para los detalles de implementación.
Para iniciar el servidor, debe ejecutar build/server/localserver.js después de construir con npm run build . Hay algunas variables de entorno que probablemente desee establecer cuando se ejecute:
NODE_ENV probablemente debería estar configurado en productionCONFIG_NAME debe establecerse en Basename (sin extensión) de su archivo de configuración que creó anteriormente. El valor predeterminado es "predeterminado".El servidor se ejecuta solo en HTTP. Probablemente desee poner un servidor web o proxy delgado HTTPS delante de él.
Ver contribuyendo para obtener información.
npm install y luego npm run dev lo despegará para el desarrollo local. Esto iniciará un contenedor Docker para PostgreSQL, pero usará una copia local de TSC, Webpack, Node, etc. para que pueda iterar rápidamente.
Una vez que las cosas han comenzado, puede abrir http://0.0.0.0:2425/webpack-dev-server/. Esto recargará automáticamente los cambios en el navegador, y el backend también se reiniciará automáticamente en los cambios en el lado del servidor.
Variables de entorno útiles:
NODE_ENV : cuando no seas o development , obtendrás mapas de origen y registros de depuraciónDEBUG_SQL : cuando se establece (a cualquier cosa), esto mostrará consultas SQL en el terminal mientras ejecutan npm test ejecutará pruebas unitarias. Estos están principalmente enfocados en el servidor.
npm run test-ui ejecutará pruebas de selenio. Puede establecer la variable de entorno SELENIUM_DRIVER si desea un controlador personalizado; de forma predeterminada, intentará usar Chrome, y si eso no está disponible, volverá a PhantomJS.
Al depurar las pruebas de interfaz de usuario, puede ser más fácil cambiar standalone-chrome a standalone-chrome-debug en docker-compose.selenium.yml , y luego conectarse al contenedor a través de VNC (puerto 5900, contraseña "secreta"). Ejecute el contenedor y sus pruebas por separado:
docker-compose -f docker-compose.selenium.yml up --buildtsc && jasmine --stop-on-failure=true 'build/selenium/*.spec.js' ¿Las pruebas que fallan por aparentemente no hay razón? driver.sleep ¿Duerme no funciona? Asegúrese de que su tiempo de espera de Jasmine en su prueba sea lo suficientemente alto.
