Enlaces útiles

omegaUp no es un programa único: son un puñado de servicios que se comunican entre sí a través de HTTP, distribuido en varios repositorios. Si alguna vez has visto omegaup/omegaup has visto la interfaz PHP y la API, pero no el evaluador Go que realmente compila y ejecuta los envíos, ni el git Servidor que almacena problemas como repositorios controlados por versión. Esta página es el mapa: cual repositorio contiene qué, por dónde empezar si desea contribuir y dónde está la API siempre actualizada vidas de referencia. Cuando un enlace apunta a un código, apunta al repositorio que posee ese código, no el monorepo, por lo que aterrizas donde realmente se debe realizar el cambio.

Los repositorios

Hay tres que importan para casi todo, además de algunos satélites. La razón por la que existe división es que las piezas están escritas en diferentes idiomas y evolucionan diferentes relojes: la interfaz es PHP + Vue y se envía en cada fusión a main, mientras que el Grader es Go y se envía como un binario versionado al que la interfaz llama a través de la red. mantener ese límite en mente: es por eso que "arreglar la cola" y "arreglar el formulario de envío" viven en diferentes repositorios.

omegaup/omegaup: la interfaz y la API

github.com/omegaup/omegaup es el grande y el uno en el que pasarás la mayor parte de tu tiempo. Es el backend de PHP 8.1 (php-fpm detrás de nginx, el código \OmegaUp\... con espacio de nombres en frontend/server/src), los componentes de archivo único de Vue 2.7 + TypeScript en frontend/www/js/omegaup/components, y toda la API REST pública. Cada controlador vive en frontend/server/src/Controllers/, y cada método apiXxx en un controlador es exactamente un punto final, por lo que Run.php's apiCreate es /api/run/create/. Lo que este repositorio no contiene es el calificador, el runner o sandbox: cuando es necesario juzgar un envío, la clase PHP \OmegaUp\Grader simplemente hace una llamada curl a OMEGAUP_GRADER_URL (predeterminado https://localhost:21680) y deja el servicio Go hace el verdadero trabajo.

omegaup/quark — calificador, corredor, locutor

github.com/omegaup/quark es el backend propiamente dicho, escrito en Go, y su propio archivo README lo describe en tres partes:

• calificador: gestiona la cola de ejecución/envío. En particular, no ejecuta nada por sí mismo; simplemente mantiene la cola y las manos trabajan. Cuando PUBLICAS un envío, esto es lo que \OmegaUp\Grader está hablando.
• corredor: solicita al evaluador nuevos envíos, luego compila y ejecuta el código dentro del omegajail sandbox con cada entrada, compara el salida a la respuesta esperada (ejecutando un validador si el problema lo necesita) y asigna un puntuación por caso. Básicamente es una interfaz bonita y distribuida para el sandbox.
• locutor: envía notificaciones en vivo a todos los participantes de un concurso o curso: las carreras se obtienen calificados, cambios en los marcadores, nuevas aclaraciones, etc.

Si está buscando un error sobre por qué un veredicto fue incorrecto o por qué la cola se detuvo, este es el repositorio, no el de PHP. La zona de pruebas en sí es un repositorio más caído: omegaup/omegajail: porque se aislan los que no son de confianza El código concursante es un problema lo suficientemente difícil como para merecer su propio proyecto.

omegaup/gitserver — problemas como repositorios de git

github.com/omegaup/gitserver es el servicio Go que almacena cada problema como su propio repositorio git: declaraciones, casos de prueba, validadores, configuraciones, todo versionado. Es por eso que editar un problema produce un historial de confirmaciones real que puedes revertir: la "base de datos" para el contenido del problema es git, no MySQL. La interfaz habla con él cada vez que un Se crea o edita el problema y el corredor lee los casos de prueba al calificarlo.

Los satélites

Estos aparecen con menos frecuencia, pero vale la pena saber que existen:

Dónde empezar a contribuir

El flujo de trabajo se encuentra en el repositorio principal y la única fuente de verdad es CONTRIBUTING.md — léelo antes de su primer RP, porque las reglas de asignación se aplican mediante la automatización, no por la buena voluntad. Algunas cosas que vale la pena saber desde el principio para no sorprenderse:

• Reclamar un problema con /assign. Puedes mantener hasta 2 asignaciones activas a la vez, y /assign solo funciona cuando alguien con asociación de repositorio abrió el problema OWNER, MEMBER o COLLABORATOR: ese filtro existe, por lo que el robot de asignación no entrega problemas que presentaron usuarios aleatorios. Si es la primera vez que contribuye, no puede autoasignarse hasta que tenga al menos un PR fusionado aquí; Hasta entonces, comente y un mantenedor ayudará.
• Configure el entorno antes que nada. El tutorial completo de Docker: brindando el contenedores, ejecutar las pruebas, sembrar usuarios de prueba y solucionar problemas para cuando el contenedor no arranca: vive en frontend/www/docs/Development-Environment-Setup-Process.md, o en la guía Configuración de desarrollo de este sitio.
• Siga las pautas de codificación. No son pedantería de estilo en sí misma; la meta-regla todo el código base que se ejecuta es explica por qué, no qué. Ver Pautas de codificación aquí, o las canónicas versión wiki.

Para el día a día, estas son las páginas a las que los mantenedores realmente dirigen a los nuevos contribuyentes:

Y las superficies de GitHub en las que vivirás:

Un puntero a la API

Todo lo que hace la interfaz web, lo hace llamando a la misma API REST pública a la que puedes llamar usted mismo: cada actualización del marcador, cada envío, cada inicio de sesión es solo una solicitud HTTP para /api/.... Las reglas son las mismas para todos ellos: HTTP simple GET o POST, JSON back, HTTPS solo (una llamada HTTP simple obtiene una redirección 301, no un éxito silencioso, porque el rastreo el tráfico del concurso es un verdadero vector de trampa), cada URL bajo https://omegaup.com/api/, y autenticación a través de un token que obtiene de user/login y lo envía de vuelta en una cookie llamada ouat. Una consecuencia que vale la pena recordar: solo puedes tener una sesión activa a la vez, por lo que Iniciar sesión mediante programación cancelará la sesión de su navegador y viceversa.

Lo único que deliberadamente no guardamos aquí es una lista mantenida manualmente de puntos finales, porque se pudriría en el momento en que alguien editara un controlador. El autoritario y siempre actual la superficie es generada desde la fuente por frontend/server/cmd/APITool.php - la misma herramienta que emite el cliente frontend escrito api.ts y api_types.ts. Para ver exactamente qué acepta y devuelve una llamada, lea el método apiXxx en su controlador en frontend/server/src/Controllers/ en lugar de confiar en cualquier mesa.

Sitios oficiales

Antecedentes académicosDos artículos de la revista IOI son los antecedentes autorizados de por qué el sistema está construido de la forma en que

Vale la pena leerlo si desea conocer la intención del diseño detrás de la arquitectura, no solo la actual. código:

• omegaUp: Sistema de gestión de concursos basado en la nube (IOI Journal, 2014): el artículo de arquitectura original.
• libinteractive: una mejor manera de escribir tareas interactivas (IOI Journal, 2015): el diseño detrás de omegaup/libinteractive.

El lugar más amplio es el IOI Journal en ioinformatics.org, y omegaUp surgió de la Olimpiada Mexicana de Informática (OMI).

Ver también

• Referencia de API: las reglas transversales para llamar a cualquier punto final.
• Partes internas del sistema: cómo una llamada run/create realmente fluye desde \OmegaUp\ApiCaller a través de un controlador y sale a la niveladora Go.
• Grader Internals y Runner Internals: qué sucede dentro del quark una vez que la interfaz entrega un envío.