Thunderstore
1.0.0
Thunderstore est une base de données de mods et une API pour télécharger des mods.
Copiez .env.template dans .env et modifiez-le comme bon vous semble - Si vous avez accès au sous-module python-packages et qu'il est cloné, assurez-vous de définir BUILD_INSTALL_EXTRAS sur true . Toute autre valeur ne fonctionnera pas. La modification de ce paramètre nécessitera de reconstruire l'environnement (par exemple avec docker compose build ) pour qu'il prenne effet.
Exécutez docker compose up
Exécutez docker compose exec django python manage.py migrate dans un autre terminal
Exécutez docker compose exec django python manage.py shell et entrez le code suivant :
à partir de django.contrib.sites.models import SiteSite.objects.create(domain="thunderstore.localhost", name="Thunderstore")
Assurez-vous de remplacer localhost par ce que vous utilisez pour vous connecter au site ! En général, vous devez utiliser thunderstore.localhost comme domaine principal pour gérer correctement la portée d'authentification (voir SESSION_COOKIE_DOMAIN plus tard)
Vous devrez également accéder au panneau d'administration ( /djangoadmin ) et configurer un mappage d'un site vers une communauté. Vous pouvez créer un compte superutilisateur avec la commande de gestion createsuperuser Django (semblable à la façon dont migrate a été exécuté) pour accéder au panneau d'administration.
Pour connecter un site à une communauté, vous devrez :
Assurez-vous qu'au moins un objet Community existe ou créez-en un ( Risk of Rain 2 devrait être créé automatiquement)
Assurez-vous qu'au moins un objet Site existe ou créez-en un
Faites en sorte que l'attribut domain name de l'objet site corresponde à celui que vous utilisez pour vous connecter à votre environnement de développement
Créez un nouvel objet Site communautaire, reliant les deux ensemble
Il existe un script pour remplir la base de données locale avec des données de test. Vous pouvez l'exécuter comme suit :
docker compose exec django python manage.py create_test_data
Dans le développement local, minio est utilisé pour le stockage de fichiers compatible S3. Vous pouvez y accéder via http://localhost:9000/ avec les informations d'identification thunderstore:thunderstore
La documentation swagger de l'API REST peut être consultée à partir de /api/docs/ .
Pour le moment, la seule API pertinente est /api/v1/package/ , qui répertorie tous les mods actifs dans la base de données. Un mod spécifique peut également être récupéré si nécessaire avec le point de terminaison /api/v1/package/{uuid4}/ , où {uuid4} est remplacé par la valeur uuid4 du mod.
Le site d'administration est accessible depuis /djangoadmin/ . Pour afficher le site d'administration, vous avez besoin d'un compte administrateur.
En supposant que Docker soit utilisé, le compte administrateur peut être créé comme suit :
docker compose exec django python manage.py createsuperuser
Notez que si vous utilisez Windows, vous devrez utiliser winpty pour exécuter cette commande.
DEBUG : doit être défini sur false ou pas du tout pour la production
SECRET_KEY : Une chaîne longue et aléatoire, utilisée pour hacher les mots de passe et autres données. Doit rester secret, comme son nom l’indique.
ALLOWED_HOSTS : liste de noms d'hôtes séparés par des virgules avec lesquels ce serveur peut être connecté. Par exemple beta.thunderstore.io
PRIMARY_HOST : Le nom public du serveur, tel que beta.thunderstore.io
PROTOCOL : Le protocole à utiliser pour créer des URL vers le serveur. Soit https:// ou http:// .
REPOSITORY_MAX_PACKAGE_SIZE_MB : La taille maximale d'un seul paquet
REPOSITORY_MAX_PACKAGE_TOTAL_SIZE_GB : La taille totale maximale du fichier utilisée par les packages
GUNICORN_WORKER_COUNT : Utilisé pour contrôler le nombre d'ouvriers gunicorn qui apparaîtront
GUNICORN_LOG_LEVEL : Utilisé pour contrôler le niveau de journalisation de Gunicorn
SESSION_COOKIE_DOMAIN : Si défini, permet le partage des sessions au sein d'un domaine et de ses sous-domaines. Par exemple : thunderstore.io
Pour les tests locaux, les valeurs recommandées sont :
SESSION_COOKIE_DOMAIN : thunderstore.localhost
Assurez-vous également que les objets Site pointent vers thunderstore.localhost ou certains de ses sous-domaines, tels que test.thunderstore.localhost .
SOCIAL_AUTH_SANITIZE_REDIRECTS : définissez sur True si vous souhaitez restreindre les domaines de redirection OAuth.
SOCIAL_AUTH_ALLOWED_REDIRECT_HOSTS : Liste des domaines de redirection OAuth autorisés, utilisée si SOCIAL_AUTH_SANITIZE_REDIRECTS est activé.
SOCIAL_AUTH_INIT_HOST : L'hôte utilisé pour les initialisations et les rappels d'authentification sociale, quel que soit l'hôte sur lequel se trouve actuellement l'utilisateur. S'il n'est pas défini, la valeur par défaut est la même que AUTH_EXCLUSIVE_HOST . Si aucun des deux n'est défini, la valeur par défaut est l'hôte de la requête.
AUTH_EXCLUSIVE_HOST : Un nom d'hôte/domaine qui sera exclusivement utilisé pour la logique liée à l'authentification, telle que le processus d'authentification sociale. S’il n’est pas défini, aucun hôte n’est traité comme hôte d’authentification exclusif.
Pour les tests locaux, les valeurs recommandées sont :
AUTH_EXCLUSIVE_HOST : auth.thunderstore.localhost
SOCIAL_AUTH_SANITIZE_REDIRECTS : auth.thunderstore.localhost,thunderstore.localhost
Pour configurer GitHub OAuth, accédez aux paramètres sur GitHub (paramètres personnels ou d'organisation), et sous Developer Settings sélectionnez OAuth Apps .
Créez une nouvelle application OAuth et utilisez {AUTH_EXCLUSIVE_HOST}/auth/complete/github/ comme URL de rappel d'autorisation, où {AUTH_EXCLUSIVE_HOST} est remplacé par la valeur utilisée pour le paramètre AUTH_EXCLUSIVE_HOST . Par exemple, pour un environnement local, vous pouvez utiliser http://auth.localhost/auth/complete/github/ , alors que pour un environnement en direct https://auth.thunderstore.dev/auth/complete/github/
Après avoir créé l'application OAuth, vous devez également fournir les variables d'environnement suivantes à l'application :
SOCIAL_AUTH_GITHUB_KEY : La valeur de Client ID de l'application OAuth
SOCIAL_AUTH_GITHUB_SECRET La valeur Client Secret de l'application OAuth
Pour configurer un Discord OAuth, accédez au panneau des développeurs Discord et créez une nouvelle application OAuth. Ajoutez une URL de rappel à {AUTH_EXCLUSIVE_HOST}/auth/complete/discord/ , où {AUTH_EXCLUSIVE_HOST} est remplacé par la valeur utilisée pour le paramètre AUTH_EXCLUSIVE_HOST . Par exemple, pour un environnement local, vous pouvez utiliser http://auth.localhost/auth/complete/discord/ , alors que pour un environnement en direct https://auth.thunderstore.dev/auth/complete/discord/
SOCIAL_AUTH_DISCORD_KEY : La valeur de Client ID de l'application OAuth
SOCIAL_AUTH_DISCORD_SECRET La valeur Client Secret de l'application OAuth
Le protocole AWS S3/Boto3 est pris en charge par plusieurs fournisseurs et services, et sa mise en œuvre peut varier en fonction du fournisseur.
Reportez-vous à https://django-storages.readthedocs.io/en/latest/backends/amazon-S3.html pour plus de détails sur l'implémentation. Consultez également Thunderstore/core/settings.py pour connaître les variables d'environnement actuellement implémentées.
Définissez au minimum les variables suivantes :
AWS_ACCESS_KEY_ID : ID de clé d'authentification
AWS_SECRET_ACCESS_KEY : clé secrète d'authentification
AWS_S3_REGION_NAME : région du compartiment de stockage
AWS_S3_ENDPOINT_URL : point de terminaison du service de stockage
AWS_STORAGE_BUCKET_NAME : nom du compartiment
AWS_LOCATION : emplacement à l'intérieur du compartiment où télécharger les fichiers
AWS_S3_SECURE_URLS : défini sur false pour désactiver HTTPS, activé par défaut
Les API usermedia fonctionnent en exploitant les URL prédéfinies de stockage compatibles S3 pour gérer le téléchargement réel. En tant que tel, le backend usermedia doit également être un backend de stockage compatible S3. De même, le backend de stockage usermedia peut être configuré avec des variables d'environnement :
USERMEDIA_S3_ENDPOINT_URL : point de terminaison du service de stockage accessible en interne
USERMEDIA_S3_ACCESS_KEY_ID : ID de clé d'authentification
USERMEDIA_S3_SECRET_ACCESS_KEY : Clé secrète d'authentification
USERMEDIA_S3_SIGNING_ENDPOINT_URL : point de terminaison du service de stockage accessible au public
USERMEDIA_S3_REGION_NAME : région du bucket de stockage
USERMEDIA_S3_STORAGE_BUCKET_NAME : Nom du bucket de stockage
USERMEDIA_S3_LOCATION : Emplacement à l'intérieur du bucket où télécharger les fichiers
La plus grande différence par rapport à la configuration AWS S3 est l'ajout d'un USERMEDIA_S3_SIGNING_ENDPOINT_URL . S'il est fourni, il sera utilisé lors de la génération d'URL pré-signées. Peut être utilisé pour contourner le domaine CDN par exemple.
La configuration de la base de données est assez simple si vous utilisez une base de données locale où aucun SSL n'est requis, mais une base de données distante via des connexions SSL est également prise en charge.
DATABASE_URL : L'URL de la base de données à utiliser pour une connexion à la base de données
DB_CLIENT_CERT : certificat client codé en base64 à utiliser pour la connexion à la base de données. Sera placé dans client-cert.pem
DB_CLIENT_KEY : clé client codée en base64 à utiliser pour la connexion à la base de données. Sera placé dans client-key.pem
DB_SERVER_CA : autorité de certification du serveur codé en base64 à utiliser pour la connexion à la base de données. Sera placé sur server-ca.pem
La base de données locale par défaut configurée dans docker-compose.yml est accessible :
Depuis le shell : docker compose exec db psql -U django
Depuis le navigateur : accédez à localhost:8080/?pgsql=db&username=django et utilisez le mot de passe django
Vous pouvez activer la mise en cache sur le backend Redis en fournissant une URL Redis
REDIS_URL : L'URL de la base de données Redis à utiliser pour la mise en cache, par exemple redis://some-host:6379/0
Les tests peuvent être exécutés avec cette commande : docker compose exec django pytest Si vous devez recréer dans la base de données, utilisez ce qui suit : docker compose exec django pytest --create-db --migrations
Le pipeline CI vérifie que les nouveaux PR ne réduisent pas la couverture des tests. Étant donné que ce processus est plutôt lent, vous souhaiterez peut-être vérifier la couverture localement avant de soumettre un PR.
Pour mettre à jour le fichier de couverture, exécutez docker compose exec django coverage run -m pytest
Pour voir le rapport de couverture, exécutez docker compose exec django coverage report -m
L'exécution du test est répartie sur plusieurs nœuds de calcul sur le pipeline CI, et la répartition vise à équilibrer le test sur tous les nœuds de calcul disponibles dans une consommation de temps égale.
Pour pouvoir le faire avec précision, la base de données sur la durée des tests doit être à jour. En tant que tel, c'est une bonne idée de mettre à jour la base de données sur la durée des tests de temps en temps.
La base de données sur la durée des tests peut être mise à jour en exécutant la suite de tests complète avec l'indicateur --store-durations . Un exemple de commande complet serait donc
docker compose exec django pytest --store-durations
