uqbar-project / yanapiri Goto Github PK

Ayudante para manejar entregas de GitHub Classroom

License: MIT License

Ruby 99.54% Shell 0.46%

yanapiri's Introduction

Yanapiri

Yanapiri es un vocablo aymara que significa "ayudante" o "el que ayuda".

A partir de este humilde aporte, es también una aplicación de línea de comandos (CLI) para asistir a docentes en ciertas tareas relacionadas al manejo de entregas a través de GitHub Classroom.

Instalación

Yanapiri funciona con Ruby, por lo cual es necesario instalarlo antes. Podés consultar cómo hacerlo en la documentación oficial.

Una vez que tu entorno Ruby esté funcionando, ejecutá lo siguiente:

gem install yanapiri

Luego, por única vez, deberás darle a yanapiri un access token de GitHub y una organización por defecto sobre la cual trabajar. Para ello, ejecutá el siguiente comando:

yanapiri setup

Uso

Podés ver una lista de los comandos existentes ejecutando yanapiri help. Un flujo de trabajo típico sería el siguiente:

yanapiri clonar entrega-1
yanapiri corregir entrega-1 --commit-base 326336a8ba771611 --fecha-limite "2019-05-01 23:59:59"

Otra opción posible, para cuando el commit base no es el mismo para todas las entregas, es especificarlo mediante un índice (con base 1). Por ejemplo, esto tomará como base al tercer commit que tenga el repositorio:

yanapiri corregir entrega-1 --commit-base index:3 --fecha-limite "2019-05-01 23:59:59"

Trabajando con más de una organización

Yanapiri soporta tres formas de configurar la organización:

global, que se configura con yanapiri setup;
local, que se configura con yanapiri init;
por parámetro, que se configura con la opción --orga.

Para los casos en que se necesite trabajar regularmente con más de una organización (por ejemplo, si tenés varios cursos) conviene utilizar la configuración local.

Un ejemplo de estructura de directorios podría ser el siguiente:

entregas
├── une-objetos1
└── unlu-intro

Para escribir la configuración local, habría que ejecutar yanapiri init en cada uno de los subdirectorios.

Pruebas locales

Para una prueba rápida, se puede instalar la gema localmente ejecutando rake install. Esto hará que el comando yanapiri ejecute el código local.

Durante el desarrollo es más cómodo no tener que correr rake install ante cada cambio, y para eso el proyecto incluye guard, una herramienta que se encarga de correrlo ante cada cambio. Basta con ejecutar bundle exec guard para que funcione (¡no olvides dejar abierta la terminal!).

Releases

Utilizamos la gema bump para generar los releases, en conjunto con gren para actualizar la información en GitHub Releases.

Las versiones se nombran según la especificación Semantic Versioning 2.0.0 y son publicadas automáticamente en RubyGems gracias a Travis.

Para publicar una nueva versión (un patch, en este ejemplo), hay que ejecutar lo siguiente:

rake bump:patch             # o bien bump:minor o bump:major
git push --follow-tags

Agradecimientos

Gracias a Elizabeth Arostegui, autora de la cholita que usamos como logo de Yanapiri. Podés ver otros íconos de esa gran colección entrando a su sitio Cosmocollita.

yanapiri's People

Contributors

Stargazers

Watchers

yanapiri's Issues

Poder especificar el commit base según su orden

Localizar mensajes

No fallar en entregas vacías

Si no hay commits entre base y entrega, yanapiri falla al querer crear el PR.

Sería bueno informarle al/a docente de la situación y además cargarle una issue al/a estudiante.

Clonar debería hacer pull si el repo ya existe

Compatibilidad con GitHub Template

Ahora GitHub permite la opción de que un repo pueda ser usado como template. Esto permite crear un nuevo repo a partir del template, pero en vez de tener toda la historia crea un solo commit inicial con tooodo el código actual.

Nosotros usamos esto con GHClassroom porque nos resuelve un problema, que tuvimos varias veces, de que se quedaba colgado la importación de código inicial.

Un problema con esto, es que ahora no existe un mismo commit base para todos los repositorios de una actividad, entonces no podemos usar Yanapiri :(

Estaría bueno poder decir en el comando "corregir" si los repos fueron creados a partir de un template para que tome como base el primer commit (quizás pueda ser un default de si no te paso un commit base ?)

Eliminar opción verbosa

Ya que conflictua con -v --version. Fijarse que siga funcionando el log.

No depender de la autenticación del sistema para hacer push

Al clonar, permitir configurar fecha límite y commit base

Iría en un archivo .yanapiri dentro de la carpeta de la entrega y serviría para no tener que especificar esos valores en cada comando posterior (ultimo-commit y corregir, por ahora).

Al corregir, no fallar si el proyecto ya había sido renombrado

Hacer un "fork" individual de un assignment grupal

Util para armar una defensa individual de un TP grupal, que requiera agregarle funcionalidades al código grupal.

Debería:

Crear un repo privado nuevo bajo la organización, con sufijo -defensa-<usuario>, para cada miembro del team.
Agregar al usuario como collaborator, con permiso de Write.
Pushear el código del repo original al nuevo.

Al corregir, indicar si algun/a estudiante ni siquiera aceptó el assignment

Para eso, habría que proveer una lista de estudiantes contra la cual comparar.

Creo que una buena opción sería usar el roster que arma GH Classroom, que tiene esta pinta (*):

"identifier","github_username","github_id","name"
"Adrian Fragata","fragata-adrian","48962799",""
"Barbara Cimino","BarbaraC96","48963013",""
"Barbara Proietto","barbyproietto","48962943",""
"Cesar Marca","96DeReK96","48963094",""
"Daniel Sorella","Magnesium998","42882024","Daniel Sorella"

(*) el identifier lo pone el/la docente. Yo en este caso elegí usar los nombres completos, pero podría ser también el mail o cualquier otra cosa.

Al preparar, falla porque intenta borrar branches remotas

Al corregir, cargar issue si no hay commits desde base

Al corregir, mostrar qué es lo que se está haciendo

Al corregir, soportar política "estricta" para la fecha límite

En caso que se elija esa opción, el PR debería crearse con el último commit anterior a la fecha límite.

Quizás agregando un mensaje al estudiante que le indique que tales commits no fueron tenidos en cuenta.

Al corregir, actualizar la branch entrega si ya existía

No funcionan las configuraciones de modo estricto y proyecto Wollok en yanapiri init

Si al ejecutar yanapiri init le digo que no renombre los proyectos Wollok, luego el corregir renombra de todas maneras. Si lo ingreso como parámetro al corregir funciona correctamente.

Tampoco toma la configuración del init de "modo estricto", no lo pude probar por parámetro.

Compartir las correcciones antes de publicar

Empezando a usar Yanapiri, un inconveniente que tuvimos con el equipo de docentes es no poder ver las correcciones que hizo otro sin publicarlas al estudiante.

Contexto

Por lo general, cuando somos varios docentes tras una materia, nos repartimos las correcciones y cada uno corrige y pune nota por sí mismo. Acá todo joya.
Pero hay algunos casos, sobre todo para parciales o exámenes finales donde se decide si el estudiante aprueba / promociona la materia, que luego de hacer las correcciones evaluamos entre varios docentes cuál es la nota final.
Acá tenemos el problema, en el que no queremos publicar las correcciones (porque todavía no decidimos la nota) pero queremos compartirlas con otros docentes para charlar sobre la nota. Por ahora lo fuimos solucionando juntándonos con las compus, pero me gustaría poder tener todas las correcciones (en pending) hechas por varias personas en una máquina.

Pensaba que una posible solución (todavía no la probé) sería tener un usuario "Docente" y que todos los docentes usen ese usuario para corregir. Pero quería ver si se les ocurre / tengan experiencia en alguna otra opción?

No renombrar proyectos Wollok los renombra igual

Hice un init en una carpeta y la configuré para que no renombre los proyectos de Wollok:

nahue@nahue-SmartPro-Q2:~/git/obj1$ yanapiri init
Nombre de la organización: (obj1) obj1unq
¿Usar modo estricto? [y/N] N
¿Renombrar proyectos Wollok al corregir? [Y/n] n
Yuspagara. De ahora en más, trabajaré con la organización obj1unq siempre que estés dentro de esta carpeta. Al corregir, utilizaré el modo relajado y no renombraré los proyectos Wollok.

Pero lo sigue haciendo cuando crea los PRs :(

Migrar a commander

El nombre de usuario se corta si tiene guiones

Poder elegir la branch 'master'

Nos pasó que mandamos un ejercicio de classroom que no tiene la branch 'master', sino que tiene otros con otros nombres. Ahora eso no nos permite usar Yanapiri (por lo que tengo entendido).

Más allá de si está bueno terner o no un branch 'master', o si quisiera corregir un trabajo a partir de otra branch, creo que estaría bueno tener la posibilidad de elegir el branch base o "master", siendo por default 'master' que es lo que pasa en la gran mayoría de los casos.

Error al intentar parsear author de Git sin nombre

Al intentar crear la entrega para este repositorio https://github.com/obj1unq/2019s1-e4-semillas-ZekielAsh/commits/master produce un error:

Traceback (most recent call last):
	20: from /usr/local/bin/yanapiri:23:in `<main>'
	19: from /usr/local/bin/yanapiri:23:in `load'
	18: from /var/lib/gems/2.5.0/gems/yanapiri-0.4.4/bin/yanapiri:5:in `<top (required)>'
	17: from /var/lib/gems/2.5.0/gems/thor-0.20.3/lib/thor/base.rb:466:in `start'
	16: from /var/lib/gems/2.5.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
	15: from /var/lib/gems/2.5.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
	14: from /var/lib/gems/2.5.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
	13: from /var/lib/gems/2.5.0/gems/yanapiri-0.4.4/lib/yanapiri/cli.rb:90:in `corregir'
	12: from /var/lib/gems/2.5.0/gems/yanapiri-0.4.4/lib/yanapiri/cli.rb:142:in `foreach_entrega'
	11: from /var/lib/gems/2.5.0/gems/yanapiri-0.4.4/lib/yanapiri/cli.rb:129:in `foreach_repo'
	10: from /var/lib/gems/2.5.0/gems/yanapiri-0.4.4/lib/yanapiri/cli.rb:129:in `chdir'
	 9: from /var/lib/gems/2.5.0/gems/yanapiri-0.4.4/lib/yanapiri/cli.rb:133:in `block in foreach_repo'
	 8: from /var/lib/gems/2.5.0/gems/yanapiri-0.4.4/lib/yanapiri/cli.rb:133:in `each'
	 7: from /var/lib/gems/2.5.0/gems/yanapiri-0.4.4/lib/yanapiri/cli.rb:134:in `block (2 levels) in foreach_repo'
	 6: from /var/lib/gems/2.5.0/gems/yanapiri-0.4.4/lib/yanapiri/cli.rb:134:in `chdir'
	 5: from /var/lib/gems/2.5.0/gems/yanapiri-0.4.4/lib/yanapiri/cli.rb:135:in `block (3 levels) in foreach_repo'
	 4: from /var/lib/gems/2.5.0/gems/yanapiri-0.4.4/lib/yanapiri/cli.rb:144:in `block in foreach_entrega'
	 3: from /var/lib/gems/2.5.0/gems/yanapiri-0.4.4/lib/yanapiri/entrega.rb:50:in `to_s'
	 2: from /var/lib/gems/2.5.0/gems/yanapiri-0.4.4/lib/yanapiri/entrega.rb:57:in `formato_humano'
	 1: from /var/lib/gems/2.5.0/gems/i18n-0.9.5/lib/i18n.rb:258:in `localize'
/var/lib/gems/2.5.0/gems/i18n-0.9.5/lib/i18n/backend/base.rb:75:in `localize': Object must be a Date, DateTime or Time object. nil given. (I18n::ArgumentError)

El problema está en esta línea en entrega.rb

      string << if hay_cambios? then "modificada por última vez #{formato_humano fecha}" else "sin cambios" end

o más bien en el método fecha que devuelve nil (o algo así), acá: @repo.log.first.author_date

Me quedé ahí no supe cómo seguir.

Mejorar vista último commit

Clonar por https

Actualmente al clonar los repos se hace por ssh, pero algunas facus tienen los puertos bloqueados y no se puede resolver el host:

ssh: connect to host github.com port 22: No route to host
fatal: Could not read from remote repository.

(Al conectarme desde mi cel me deja clonar sin problemas).

Estaría bueno tener la opción o de alguna manera poder clonar los repos por https.

una global, que se configura al principio con un comando tipo yanapiri setup;
una por carpeta, que se configura con yanapiri init;
una para una ejecución en particular, que va por parámetro --orga obj1-unahur