Thunderstore
1.0.0
Thunderstore es una base de datos de mods y una API para descargar mods.
Copie .env.template a .env y modifíquelo como mejor le parezca. Si tiene acceso al submódulo de python-packages y está clonado, asegúrese de configurar BUILD_INSTALL_EXTRAS en true . Cualquier otro valor no funcionará. Cambiar esta configuración requerirá reconstruir el entorno (por ejemplo, con docker compose build ) para que surta efecto.
Ejecutar docker compose up
Ejecute docker compose exec django python manage.py migrate en otra terminal
Ejecute docker compose exec django python manage.py shell e ingrese el siguiente código:
desde django.contrib.sites.models importe SiteSite.objects.create(domain="thunderstore.localhost", nombre="Thunderstore")
¡Asegúrate de sustituir localhost por lo que utilizas para conectarte al sitio! En general, debes usar thunderstore.localhost como dominio principal para manejar el alcance de autenticación correctamente (consulta SESSION_COOKIE_DOMAIN más adelante).
También deberá navegar hasta el panel de administración ( /djangoadmin ) y configurar una asignación de un sitio a una comunidad. Puede crear una cuenta de superusuario con el comando de administración createsuperuser Django (similar a cómo se ejecutó migrar) para obtener acceso al panel de administración.
Para conectar un sitio a una comunidad, necesitará:
Asegúrese de que exista al menos un objeto comunitario o cree uno ( Risk of Rain 2 debe crearse automáticamente)
Asegúrese de que exista al menos un objeto de sitio o cree uno
Haga que el atributo domain name del objeto del sitio coincida con el que utiliza para conectarse a su entorno de desarrollo.
Cree un nuevo objeto de sitio comunitario, vinculando los dos.
Hay un script para completar la base de datos local con datos de prueba. Puedes ejecutarlo de la siguiente manera:
ventana acoplable componer ejecutivo django python administrar.py create_test_data
En el desarrollo local, minio se utiliza para el almacenamiento de archivos compatibles con S3. Puede acceder a él a través de http://localhost:9000/ con las credenciales thunderstore:thunderstore
La documentación de arrogancia de la API REST se puede ver en /api/docs/ .
En este momento, la única API relevante es /api/v1/package/ , que enumera todas las modificaciones activas en la base de datos. También se puede recuperar un mod específico si es necesario con el punto final /api/v1/package/{uuid4}/ , donde {uuid4} se reemplaza con el valor uuid4 del mod.
Se puede acceder al sitio de administración desde /djangoadmin/ . Para ver el sitio de administración, necesita una cuenta de administrador.
Suponiendo que se esté utilizando Docker, la cuenta de administrador se puede crear de la siguiente manera:
docker compose exec django python manage.py createsuperuser
Tenga en cuenta que si está ejecutando Windows, necesitará usar winpty para ejecutar ese comando.
DEBUG : Debe establecerse en falso o no establecerse en absoluto para producción
SECRET_KEY : una cadena larga y aleatoria, que se utiliza para codificar contraseñas y otros datos. Debe permanecer en secreto, como su nombre lo indica.
ALLOWED_HOSTS : Lista separada por comas de nombres de host a los que se puede conectar este servidor. Por ejemplo beta.thunderstore.io
PRIMARY_HOST : el nombre público del servidor, como beta.thunderstore.io
PROTOCOL : El protocolo que se utilizará para crear URL para el servidor. Ya sea https:// o http:// .
REPOSITORY_MAX_PACKAGE_SIZE_MB : el tamaño máximo de paquete único
REPOSITORY_MAX_PACKAGE_TOTAL_SIZE_GB : el tamaño total máximo de archivo utilizado por los paquetes
GUNICORN_WORKER_COUNT : Se utiliza para controlar cuántos trabajadores generará gunicorn.
GUNICORN_LOG_LEVEL : Se utiliza para controlar el nivel de registro de gunicorn.
SESSION_COOKIE_DOMAIN : si se establece, permite compartir sesiones dentro de un dominio y sus subdominios. Por ejemplo: thunderstore.io
Para pruebas locales, los valores recomendados son:
SESSION_COOKIE_DOMAIN : thunderstore.localhost
Asegúrese también de que los objetos del sitio apunten a thunderstore.localhost o algunos de sus subdominios, como test.thunderstore.localhost .
SOCIAL_AUTH_SANITIZE_REDIRECTS : configúrelo en True si desea restringir los dominios de redireccionamiento de OAuth.
SOCIAL_AUTH_ALLOWED_REDIRECT_HOSTS : Lista de dominios de redirección de OAuth permitidos, utilizada si SOCIAL_AUTH_SANITIZE_REDIRECTS está habilitado.
SOCIAL_AUTH_INIT_HOST : el host utilizado para las inicializaciones y devoluciones de llamadas de autenticación social, independientemente del host en el que se encuentre actualmente el usuario. Si no se establece, el valor predeterminado es el mismo que AUTH_EXCLUSIVE_HOST . Si no se establece ninguno, el valor predeterminado es el host de la solicitud.
AUTH_EXCLUSIVE_HOST : un nombre de host/dominio que se utilizará exclusivamente para la lógica relacionada con la autenticación, como el proceso de autenticación social. Si no se establece, ningún host se trata como host de autenticación exclusivo.
Para pruebas locales, los valores recomendados son:
AUTH_EXCLUSIVE_HOST : auth.thunderstore.localhost
SOCIAL_AUTH_SANITIZE_REDIRECTS : auth.thunderstore.localhost,thunderstore.localhost
Para configurar GitHub OAuth, diríjase a la configuración de GitHub (ya sea configuración personal u organizacional) y, en Developer Settings seleccione OAuth Apps .
Cree una nueva aplicación OAuth y use {AUTH_EXCLUSIVE_HOST}/auth/complete/github/ como URL de devolución de llamada de autorización, donde {AUTH_EXCLUSIVE_HOST} se reemplaza con el valor que se usó para la configuración AUTH_EXCLUSIVE_HOST . Por ejemplo, para local podrías usar http://auth.localhost/auth/complete/github/ , mientras que para un entorno en vivo https://auth.thunderstore.dev/auth/complete/github/
Después de crear la aplicación OAuth, también debe proporcionar las siguientes variables de entorno a la aplicación:
SOCIAL_AUTH_GITHUB_KEY : el valor Client ID de la aplicación OAuth
SOCIAL_AUTH_GITHUB_SECRET El valor Client Secret de la aplicación OAuth
Para configurar Discord OAuth, diríjase al panel de desarrollador de Discord y cree una nueva aplicación OAuth. Agregue una URL de devolución de llamada a {AUTH_EXCLUSIVE_HOST}/auth/complete/discord/ , donde {AUTH_EXCLUSIVE_HOST} se reemplaza con el valor que se usó para la configuración AUTH_EXCLUSIVE_HOST . Por ejemplo, para local, puede usar http://auth.localhost/auth/complete/discord/ , mientras que para un entorno en vivo https://auth.thunderstore.dev/auth/complete/discord/
SOCIAL_AUTH_DISCORD_KEY : el valor Client ID de la aplicación OAuth
SOCIAL_AUTH_DISCORD_SECRET El valor Client Secret de la aplicación OAuth
El protocolo AWS S3/Boto3 es compatible con múltiples proveedores y servicios, y su implementación puede variar según el proveedor.
Consulte https://django-storages.readthedocs.io/en/latest/backends/amazon-S3.html para obtener más detalles sobre la implementación. Consulte también thunderstore/core/settings.py para conocer qué variables de entorno están implementadas actualmente.
Como mínimo establezca las siguientes variables:
AWS_ACCESS_KEY_ID : ID de clave de autenticación
AWS_SECRET_ACCESS_KEY : Secreto de clave de autenticación
AWS_S3_REGION_NAME : región del depósito de almacenamiento
AWS_S3_ENDPOINT_URL : punto final del servicio de almacenamiento
AWS_STORAGE_BUCKET_NAME : nombre del depósito
AWS_LOCATION : Ubicación dentro del depósito donde cargar archivos
AWS_S3_SECURE_URLS : Establecer en falso para deshabilitar HTTPS, habilitado de forma predeterminada
Las API de medios de usuario funcionan aprovechando las URL prefirmadas de almacenamiento compatible con S3 para manejar la carga real. Como tal, el backend de medios de usuario también debe ser un backend de almacenamiento compatible con S3. Asimismo, el backend de almacenamiento de medios de usuario se puede configurar con variables de entorno:
USERMEDIA_S3_ENDPOINT_URL : punto final del servicio de almacenamiento accesible internamente
USERMEDIA_S3_ACCESS_KEY_ID : ID de clave de autenticación
USERMEDIA_S3_SECRET_ACCESS_KEY : Secreto de clave de autenticación
USERMEDIA_S3_SIGNING_ENDPOINT_URL : punto final del servicio de almacenamiento de acceso público
USERMEDIA_S3_REGION_NAME : región del depósito de almacenamiento
USERMEDIA_S3_STORAGE_BUCKET_NAME : nombre del depósito de almacenamiento
USERMEDIA_S3_LOCATION : Ubicación dentro del depósito donde cargar archivos
La mayor diferencia en comparación con la configuración de AWS S3 es la adición de USERMEDIA_S3_SIGNING_ENDPOINT_URL . Si se proporciona, se utilizará al generar URL prefirmadas. Puede usarse para omitir el dominio CDN, por ejemplo.
La configuración de la base de datos es bastante sencilla si se utiliza una base de datos local donde no se requiere SSL, pero también se admite una base de datos remota a través de conexiones SSL.
DATABASE_URL : la URL de la base de datos que se utilizará para una conexión de base de datos.
DB_CLIENT_CERT : certificado de cliente codificado en Base64 que se utilizará para la conexión de la base de datos. Se colocará en client-cert.pem
DB_CLIENT_KEY : clave de cliente codificada en Base64 que se utilizará para la conexión de la base de datos. Se colocará en client-key.pem
DB_SERVER_CA : CA del servidor codificada en Base64 que se utilizará para la conexión de la base de datos. Se colocará en server-ca.pem
Se puede acceder a la base de datos local predeterminada configurada en docker-compose.yml :
Desde shell: docker compose exec db psql -U django
Desde el navegador: navegue hasta localhost:8080/?pgsql=db&username=django y use la contraseña django
Puede habilitar el almacenamiento en caché en el backend de Redis proporcionando una URL de Redis.
REDIS_URL : la URL de la base de datos de Redis que se utilizará para el almacenamiento en caché, por ejemplo, redis://some-host:6379/0
Las pruebas se pueden ejecutar con este comando: docker compose exec django pytest Si necesita recrear la base de datos, use lo siguiente: docker compose exec django pytest --create-db --migrations
La canalización de CI verifica que los nuevos RP no reduzcan la cobertura de la prueba. Dado que este proceso es bastante lento, es posible que desees verificar la cobertura localmente antes de enviar un PR.
Para actualizar el archivo de cobertura, ejecute docker compose exec django coverage run -m pytest
Para ver el informe de cobertura, ejecute docker compose exec django coverage report -m
La ejecución de la prueba se divide entre varios trabajadores en la canalización de CI y la división tiene como objetivo equilibrar la prueba entre todos los trabajadores disponibles en cantidades iguales de tiempo.
Para poder hacerlo con precisión, la base de datos de duración de las pruebas debe estar actualizada. Como tal, es una buena idea actualizar la base de datos de duración de la prueba de vez en cuando.
La base de datos de duración de la prueba se puede actualizar ejecutando el conjunto de pruebas completo con el indicador --store-durations . Entonces un ejemplo de comando completo sería
ventana acoplable componer ejecutivo django pytest --store-durations
