Thunderstore
1.0.0
Thunderstore é um banco de dados de mods e uma API para download de mods.
Copie .env.template para .env e modifique como achar adequado - Se você tiver acesso ao submódulo python-packages e ele estiver clonado, certifique-se de definir BUILD_INSTALL_EXTRAS como true . Qualquer outro valor não funcionará. Alterar esta configuração exigirá a reconstrução do ambiente (por exemplo, com docker compose build ) para que ela tenha efeito.
Execute docker compose up
Execute docker compose exec django python manage.py migrate em outro terminal
Execute docker compose exec django python manage.py shell e insira o seguinte código:
de django.contrib.sites.models import SiteSite.objects.create(domain="thunderstore.localhost", name="Thunderstore")
Certifique-se de substituir localhost pelo que você usa para se conectar ao site! Em geral, você deve usar thunderstore.localhost como domínio principal para lidar corretamente com o escopo de autenticação (consulte SESSION_COOKIE_DOMAIN mais tarde)
Você também precisará navegar até o painel de administração ( /djangoadmin ) e configurar um mapeamento de um site para uma comunidade. Você pode criar uma conta de superusuário com o comando de gerenciamento createsuperuser do Django (semelhante a como a migração foi executada) para obter acesso ao painel de administração.
Para conectar um site a uma comunidade, você precisará:
Certifique-se de que exista pelo menos um objeto comunitário ou crie um ( Risk of Rain 2 deve ser criado automaticamente)
Certifique-se de que exista pelo menos um objeto Site ou crie um
Faça com que o atributo domain name do objeto de site corresponda ao que você usa para se conectar ao seu ambiente de desenvolvimento
Crie um novo objeto Site da comunidade, vinculando os dois
Existe um script para preencher o banco de dados local com dados de teste. Você pode executá-lo da seguinte maneira:
docker compose exec django python manage.py create_test_data
No desenvolvimento local, o minio é usado para armazenamento de arquivos compatível com S3. Você pode acessá-lo via http://localhost:9000/ com credenciais thunderstore:thunderstore
A documentação do swagger da API REST pode ser visualizada em /api/docs/ .
No momento, a única API relevante é /api/v1/package/ , que lista todos os mods ativos no banco de dados. Um mod específico também pode ser obtido, se necessário, com o endpoint /api/v1/package/{uuid4}/ , onde {uuid4} é substituído pelo valor uuid4 do mod.
O site de administração pode ser acessado em /djangoadmin/ . Para visualizar o site de administração, você precisa de uma conta de administrador.
Supondo que o docker esteja sendo usado, a conta de administrador pode ser criada da seguinte forma:
docker compose exec django python manage.py createsuperuser
Observe que se estiver executando o Windows, você precisará usar o winpty para executar esse comando.
DEBUG : Deve ser definido como falso ou não para produção
SECRET_KEY : Uma string longa e aleatória, usada para hash de senhas e outros dados. Deve permanecer secreto, como o nome indica.
ALLOWED_HOSTS : lista separada por vírgulas de nomes de host com os quais este servidor pode se conectar. Por exemplo beta.thunderstore.io
PRIMARY_HOST : O nome público do servidor, como beta.thunderstore.io
PROTOCOL : O protocolo a ser usado para construir URLs para o servidor. Ou https:// ou http:// .
REPOSITORY_MAX_PACKAGE_SIZE_MB : o tamanho máximo do pacote único
REPOSITORY_MAX_PACKAGE_TOTAL_SIZE_GB : O tamanho máximo total do arquivo usado pelos pacotes
GUNICORN_WORKER_COUNT : Usado para controlar quantos trabalhadores o gunicorn irá gerar
GUNICORN_LOG_LEVEL : Usado para controlar o nível de registro do gunicorn
SESSION_COOKIE_DOMAIN : Se definido, permite que sessões sejam compartilhadas dentro de um domínio e seus subdomínios. Por exemplo: thunderstore.io
Para testes locais, os valores recomendados são:
SESSION_COOKIE_DOMAIN : thunderstore.localhost
Certifique-se também de que os objetos Site apontem para thunderstore.localhost ou alguns de seus subdomínios, como test.thunderstore.localhost .
SOCIAL_AUTH_SANITIZE_REDIRECTS : Defina como True se desejar restringir domínios de redirecionamento OAuth.
SOCIAL_AUTH_ALLOWED_REDIRECT_HOSTS : Lista domínios de redirecionamento OAuth permitidos, usados se SOCIAL_AUTH_SANITIZE_REDIRECTS estiver habilitado.
SOCIAL_AUTH_INIT_HOST : o host usado para inicializações e retornos de chamada de autenticação social, independentemente de qual host o usuário está atualmente. Se não for definido, o padrão é o mesmo valor de AUTH_EXCLUSIVE_HOST . Se nenhum deles estiver definido, o padrão será o host da solicitação.
AUTH_EXCLUSIVE_HOST : um nome de host/domínio que será usado exclusivamente para lógica relacionada à autenticação, como o processo de autenticação social. Se não for definido, nenhum host será tratado como host de autenticação exclusivo.
Para testes locais, os valores recomendados são:
AUTH_EXCLUSIVE_HOST : auth.thunderstore.localhost
SOCIAL_AUTH_SANITIZE_REDIRECTS : auth.thunderstore.localhost,thunderstore.localhost
Para configurar o GitHub OAuth, vá para as configurações no GitHub (configurações pessoais ou da organização) e, em Developer Settings selecione OAuth Apps .
Crie um novo aplicativo OAuth e use {AUTH_EXCLUSIVE_HOST}/auth/complete/github/ como URL de retorno de chamada de autorização, onde {AUTH_EXCLUSIVE_HOST} é substituído pelo valor que foi usado para a configuração AUTH_EXCLUSIVE_HOST . Por exemplo, para local, você pode usar http://auth.localhost/auth/complete/github/ , enquanto para um ambiente ativo https://auth.thunderstore.dev/auth/complete/github/
Depois de criar o aplicativo OAuth, você também deverá fornecer as seguintes variáveis de ambiente ao aplicativo:
SOCIAL_AUTH_GITHUB_KEY : o valor Client ID do aplicativo OAuth
SOCIAL_AUTH_GITHUB_SECRET O valor Client Secret do aplicativo OAuth
Para configurar um Discord OAuth, vá para o painel do desenvolvedor Discord e crie um novo aplicativo OAuth. Adicione um URL de retorno de chamada a {AUTH_EXCLUSIVE_HOST}/auth/complete/discord/ , onde {AUTH_EXCLUSIVE_HOST} é substituído pelo valor que foi usado para a configuração AUTH_EXCLUSIVE_HOST . Por exemplo, para local você pode usar http://auth.localhost/auth/complete/discord/ , enquanto para um ambiente ao vivo https://auth.thunderstore.dev/auth/complete/discord/
SOCIAL_AUTH_DISCORD_KEY : o valor Client ID do aplicativo OAuth
SOCIAL_AUTH_DISCORD_SECRET O valor Client Secret do aplicativo OAuth
O protocolo AWS S3/Boto3 é suportado por vários fornecedores e serviços, e tal implementação pode variar dependendo do provedor.
Consulte https://django-storages.readthedocs.io/en/latest/backends/amazon-S3.html para obter mais detalhes sobre a implementação. Consulte também Thunderstore/core/settings.py para saber quais variáveis de ambiente estão implementadas atualmente.
No mínimo defina as seguintes variáveis:
AWS_ACCESS_KEY_ID : ID da chave de autenticação
AWS_SECRET_ACCESS_KEY : segredo da chave de autenticação
AWS_S3_REGION_NAME : região do bucket de armazenamento
AWS_S3_ENDPOINT_URL : endpoint do serviço de armazenamento
AWS_STORAGE_BUCKET_NAME : nome do intervalo
AWS_LOCATION : local dentro do bucket onde fazer upload de arquivos
AWS_S3_SECURE_URLS : definido como falso para desabilitar HTTPS, habilitado por padrão
As APIs usermedia funcionam aproveitando URLs pré-assinados de armazenamento compatíveis com S3 para lidar com o upload real. Como tal, o back-end usermedia também deve ser um back-end de armazenamento compatível com S3. Da mesma forma, o backend de armazenamento usermedia pode ser configurado com variáveis de ambiente:
USERMEDIA_S3_ENDPOINT_URL : endpoint de serviço de armazenamento acessível internamente
USERMEDIA_S3_ACCESS_KEY_ID : ID da chave de autenticação
USERMEDIA_S3_SECRET_ACCESS_KEY : segredo da chave de autenticação
USERMEDIA_S3_SIGNING_ENDPOINT_URL : endpoint de serviço de armazenamento acessível publicamente
USERMEDIA_S3_REGION_NAME : região do intervalo de armazenamento
USERMEDIA_S3_STORAGE_BUCKET_NAME : nome do intervalo de armazenamento
USERMEDIA_S3_LOCATION : local dentro do bucket para fazer upload dos arquivos
A maior diferença em comparação com a configuração AWS S3 é a adição de USERMEDIA_S3_SIGNING_ENDPOINT_URL . Se fornecido, será usado ao gerar URLs pré-assinados. Pode ser usado para ignorar o domínio CDN, por exemplo.
A configuração do banco de dados é bastante simples se estiver usando um banco de dados local onde nenhum SSL é necessário, mas banco de dados remoto via conexões SSL também é suportado.
DATABASE_URL : o URL do banco de dados a ser usado para uma conexão de banco de dados
DB_CLIENT_CERT : certificado de cliente codificado em Base64 a ser usado para a conexão com o banco de dados. Será colocado em client-cert.pem
DB_CLIENT_KEY : chave do cliente codificada em Base64 a ser usada para a conexão com o banco de dados. Será colocado em client-key.pem
DB_SERVER_CA : CA do servidor codificado em Base64 a ser usado para a conexão com o banco de dados. Será colocado em server-ca.pem
O banco de dados local padrão configurado em docker-compose.yml pode ser acessado:
Do shell: docker compose exec db psql -U django
Do navegador: navegue até localhost:8080/?pgsql=db&username=django e use a senha django
Você pode habilitar o cache para o back-end do redis fornecendo um URL do redis
REDIS_URL : o URL do banco de dados redis a ser usado para armazenamento em cache, por exemplo, redis://some-host:6379/0
Os testes podem ser executados com este comando: docker compose exec django pytest Se você precisar recriar o banco de dados, use o seguinte: docker compose exec django pytest --create-db --migrations
O pipeline de CI verifica se os novos PRs não reduzem a cobertura do teste. Como esse processo é bastante lento, convém verificar a cobertura localmente antes de enviar um PR.
Para atualizar o arquivo de cobertura, execute docker compose exec django coverage run -m pytest
Para ver o relatório de cobertura, execute docker compose exec django coverage report -m
A execução do teste é dividida entre vários trabalhadores no pipeline de CI, e a divisão visa equilibrar o teste entre todos os trabalhadores disponíveis em quantidades iguais de consumo de tempo.
Para poder fazer isso com precisão, o banco de dados de duração do teste deve estar atualizado. Como tal, é uma boa ideia atualizar o banco de dados de duração do teste de vez em quando.
O banco de dados de duração do teste pode ser atualizado executando o conjunto de testes completo com o sinalizador --store-durations . Portanto, um exemplo de comando completo seria
docker compose exec django pytest --store-durations
