valtersit/wordpress-cve-scannerEscaneie seu núcleo, temas e plugins do WordPress em busca de CVEs conhecidas a partir da linha de comando. Código aberto, auditável, com foco na privacidade — alimentado pela API de CVE da ValtersIT.
Para facilitar a sua introdução ao GitLab, aqui está uma lista de próximos passos recomendados.
Já é um profissional? Basta editar este README.md e torná-lo seu. Quer facilitar? Use o modelo na parte inferior!
cd existing_repo
git remote add origin https://gitlab.com/valtersit/wordpress-cve-scanner.git
git branch -M main
git push -uf origin main
Use a integração contínua integrada no GitLab.
Quando estiver pronto para tornar este README seu, basta editar este arquivo e usar o modelo prático abaixo (ou sinta-se à vontade para estruturá-lo como quiser - este é apenas um ponto de partida!). Agradecimentos a makeareadme.com por este modelo.
Cada projeto é diferente, então considere quais dessas seções se aplicam ao seu. As seções usadas no modelo são sugestões para a maioria dos projetos de código aberto. Também tenha em mente que, embora um README possa ser muito longo e detalhado, muito longo é melhor do que muito curto. Se você acha que seu README está muito longo, considere utilizar outra forma de documentação em vez de cortar informações.
Escolha um nome autoexplicativo para o seu projeto.
Deixe as pessoas saberem o que seu projeto pode fazer especificamente. Forneça contexto e adicione um link para qualquer referência com a qual os visitantes possam não estar familiarizados. Uma lista de Recursos ou uma subseção de Contexto também pode ser adicionada aqui. Se houver alternativas ao seu projeto, este é um bom lugar para listar fatores diferenciadores.
Em alguns READMEs, você pode ver pequenas imagens que transmitem metadados, como se todos os testes estão passando para o projeto. Você pode usar o Shields para adicionar alguns ao seu README. Muitos serviços também têm instruções para adicionar um badge.
Dependendo do que você está fazendo, pode ser uma boa ideia incluir capturas de tela ou até mesmo um vídeo (você verá frequentemente GIFs em vez de vídeos reais). Ferramentas como ttygif podem ajudar, mas confira o Asciinema para um método mais sofisticado.
Dentro de um ecossistema específico, pode haver uma maneira comum de instalar coisas, como usar Yarn, NuGet ou Homebrew. No entanto, considere a possibilidade de que quem está lendo seu README seja um novato e gostaria de mais orientação. Listar etapas específicas ajuda a remover ambiguidades e faz com que as pessoas comecem a usar seu projeto o mais rápido possível. Se ele só funciona em um contexto específico, como uma versão específica de linguagem de programação ou sistema operacional, ou tem dependências que precisam ser instaladas manualmente, adicione também uma subseção de Requisitos.
Use exemplos liberalmente e mostre a saída esperada, se puder. É útil ter inline o menor exemplo de uso que você pode demonstrar, enquanto fornece links para exemplos mais sofisticados se forem muito longos para incluir razoavelmente no README.
Diga às pessoas onde elas podem ir para obter ajuda. Pode ser qualquer combinação de um rastreador de issues, uma sala de chat, um endereço de e-mail, etc.
Se você tem ideias para lançamentos futuros, é uma boa ideia listá-las no README.
Declare se você está aberto a contribuições e quais são seus requisitos para aceitá-las.
Para pessoas que querem fazer alterações no seu projeto, é útil ter alguma documentação sobre como começar. Talvez haja um script que elas devam executar ou algumas variáveis de ambiente que precisam definir. Torne essas etapas explícitas. Essas instruções também podem ser úteis para você no futuro.
Você também pode documentar comandos para lint do código ou executar testes. Essas etapas ajudam a garantir alta qualidade de código e reduzem a probabilidade de que as alterações quebrem algo inadvertidamente. Ter instruções para executar testes é especialmente útil se exigir configuração externa, como iniciar um servidor Selenium para testes em um navegador.
Mostre sua apreciação àqueles que contribuíram para o projeto.
Para projetos de código aberto, diga como ele é licenciado.
Se você ficou sem energia ou tempo para o seu projeto, coloque uma nota no topo do README dizendo que o desenvolvimento diminuiu ou parou completamente. Alguém pode optar por fazer um fork do seu projeto ou se voluntariar para assumir como mantenedor ou proprietário, permitindo que seu projeto continue. Você também pode fazer um pedido explícito por mantenedores.