oss attribution builder

OSS Builder de atribuição

OSS Attribution Builder é um site que ajuda as equipes a criar documentos de atribuição para produtos de software. Um documento de atribuição é um arquivo de texto, página da web ou tela em quase todos os aplicativos de software que lista os componentes de software usados ​​e suas licenças. Eles geralmente estão nas telas sobre as telas e às vezes são rotuladas como "avisos de código aberto", "créditos" ou outros jargões semelhantes.

Captura de tela

Investir rápido

1. Instale o docker
2. Clone este repositório
3. Execute docker-compose up
4. Visite http: // localhost: 8000/
   • A demonstração usa http básico auth. Digite qualquer nome de usuário e senha. Use admin para testar a funcionalidade do administrador.

Usando o site

Consulte Documentação:

• Para usuários
• Para administradores

Advertências

O construtor de atribuições era originalmente uma ferramenta interna da Amazon. Algumas partes tiveram que ser removidas para tornar este um projeto de código aberto sensato. Como tal, existem algumas verrugas:

• Os projetos têm listas de contatos, mas no momento a interface do usuário suporta apenas um contato (o contato legal).

Tudo isso será corrigido a tempo, mas esteja ciente de que algumas coisas podem ser estranhas por um tempo.

Implantação personalizada

Se você estiver pronto para integrar o construtor de atribuição ao seu próprio ambiente, há algumas coisas para configurar:

Configuração

Abra o config/default.js e cutuca. Essa configuração é lançada quando você executa docker-compose ou inicia o aplicativo.

Licenças

O construtor de atribuições tem suporte para dois tipos de definições de licença:

• Identificadores SPDX
• Textos e tags de licença "conhecidos"

Os identificadores SPDX são usados ​​apenas para preencher o seletor de licença, mas não possuem (atualmente) textos. O tipo mais útil de licença é uma licença "conhecida", onde você (o administrador) fornece o texto da licença e quaisquer tags que você deseja aplicar.

Para obter informações sobre como adicionar suas próprias licenças "conhecidas", consulte a licença ReadMe. Existem duas licenças existentes no mesmo diretório que você pode procurar por exemplos.

Tags

As tags permitem adicionar regras de validação arbitrárias a uma licença. Eles podem ser úteis para:

• Verificar uma licença está sendo usada da maneira certa (por exemplo, LGPL e como um pacote foi vinculado)
• Anotar uma licença específica como precisando de acompanhamento, se sua empresa tiver processos especiais
• Fornecendo orientação sobre atribuição para licenças com muitas variantes
• Modificando a maneira como uma licença é exibida em um documento de atribuição

Para obter informações sobre o que as tags podem fazer e como criar o seu próprio, consulte as tags ReadMe.

Extensões

O construtor de atribuições oferece alguma forma de extensões que permitem alterar o comportamento e a aparência do site do lado do cliente, sem precisar corrigir os internos. Isso pode tornar as atualizações mais fáceis.

Veja as extensões Readme para obter detalhes.

Módulo de autenticação

O construtor de atribuições apóia a capacidade de restringir o acesso a certas pessoas ou grupos usando ACLs do projeto. Eles também podem ser usados ​​para administração e para "verificar" os pacotes (detalhes sobre isso em uma seção posterior). A implementação padrão nullauth não é muito útil para a maioria dos ambientes; Você vai querer escrever o seu próprio ao lançar de maneira mais ampla.

Consulte a interface de autenticação básica para obter detalhes da implementação.

Correndo

Para iniciar o servidor, você deve executar build/server/localserver.js após a construção do npm run build . Existem algumas variáveis ​​de ambiente que você provavelmente deseja definir ao executar:

• NODE_ENV provavelmente deve ser definido para production
• CONFIG_NAME deve ser definido como o nome da base (sem extensão) do seu arquivo de configuração criado acima. O padrão é "padrão".

O servidor é executado apenas no HTTP. Você provavelmente deseja colocar um fino servidor da web https ou proxy na frente dele.

Contribuindo

Consulte Contribuindo para obter informações.

Desenvolvimento

npm install e, em seguida, npm run dev o tirará do terreno para o desenvolvimento local. Isso iniciará um contêiner do Docker para o PostgreSQL, mas usará uma cópia local do TSC, Webpack, Node, etc. para que você possa iterar rapidamente.

Depois que as coisas começarem, você pode abrir http://0.0.0.0:2425/webpack-dev-server/. Isso recarregará automaticamente as alterações do navegador e o back-end também reiniciará automaticamente as alterações do lado do servidor.

Variáveis ​​de ambiente úteis:

• NODE_ENV : quando não serem definidos ou development , você receberá mapas de origem e logs de depuração completos
• DEBUG_SQL : Quando definido (para qualquer coisa), isso mostrará consultas SQL no terminal enquanto executam

Teste

npm test executará testes de unidade. Estes são principalmente focados no servidor.

npm run test-ui executará testes de selênio. Você pode definir a variável de ambiente SELENIUM_DRIVER se desejar um driver personalizado - por padrão, ele tentará usar o Chrome e, se não estiver disponível, ele voltará aos Phantomjs.

Ao depurar os testes da interface do usuário, pode ser mais fácil alterar standalone-chrome para standalone-chrome-debug no docker-compose.selenium.yml e, em seguida, conecte-se ao contêiner via VNC (porta 5900, senha "Secret"). Execute o contêiner e seus testes separadamente:

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

Testes falhando aparentemente sem motivo? driver.sleep não está funcionando? Verifique se o tempo limite do seu Jasmine no seu teste é alto o suficiente.