Intentando enviar un plugin, estoy recibiendo este error al descomprimir redis.
¿Quizás --long=30 es el problema? No tengo muy claro cómo intentar depurar esto…
1 me gusta
Creo que el error dice que no puede ejecutar zstd. ¿Tienes ese paquete instalado?
No. Quizás algo cambió en la imagen base de Docker, o en el sistema operativo con el que se creó y necesita agregarse allí. Realmente no está claro dónde debería suceder eso, pero estoy bastante seguro de que no está en mi plugin. 
El requisito de zstd proviene del paquete de redis (descargado en tu captura de pantalla) que está comprimido con zstd. Si zstd no era necesario antes, es posible que el método de compresión haya cambiado en el lado de shogo82148/actions-setup-redis.
1 me gusta
Si estás usando nuestra imagen base, no deberías configurar ningún Redis, ya que ya está ahí.
Siempre intento hacer todo a tu manera. 
Estoy usando la imagen base y el proceso descrito en:
Funcionó la semana pasada. No hay un nuevo commit en esos flujos de trabajo en 2 meses. No creo que haya algo que haya podido hacer en mi plugin para romper esto de esta manera en particular.
Ese proceso se actualizó el 15 de septiembre para eliminar esa acción de Redis, ¿no?
1 me gusta
¡Eso es todo! ¿Hay alguna forma recomendada/fácil de evitar que esto suceda y no parecer tan tonto?
1 me gusta
No estoy seguro, para ser honesto 
La lucha eterna entre esos proyectos esqueléticos y las actualizaciones continuas es bastante común, y aunque se pueden resolver mediante la composición de algunos archivos de configuración en algunos lugares, a veces aún necesitarás compararlos manualmente.
Es un problema constante en mi distribución de Linux actual, así que te entiendo.
1 me gusta
¡Ja! Al menos estoy en buena compañía. Eso es de gran ayuda.
Sí. Hoy me llevó unos 15 minutos averiguar cómo actualizar node.js.
1 me gusta
No estoy familiarizado con los procesos involucrados en el uso de ese proyecto esqueleto, pero ¿podrías aprovechar las alias de shell en cualquier caso? Por ejemplo, en lugar de usar docker whizzy things, entrénate para usar tu propia alias como alias dwt="git pull; docker whizzy things"
Lamentablemente, no. Una solución improvisada podría implicar enlaces duros entre mi plugin y el plugin esqueleto y alguna forma automatizada de extraer los últimos commits del esqueleto. Me temo que la solución de “esperar hasta que se rompa y recordar revisar los flujos de trabajo de GitHub” es el camino a seguir.
Gracias.
Si lo interpreto correctamente, creo que probablemente tengas una copia del proyecto esqueleto (con todo lo importante reemplazado por la magia de tu propio plugin) y el problema es que los archivos de flujo de trabajo en esa copia se desactualizan.
¿Podrías añadir el repositorio esqueleto como un submódulo y luego reemplazar los archivos de flujo de trabajo en tu repositorio con enlaces simbólicos al submódulo? Establecer git config submodule.recurse true mantendrá el submódulo actualizado cada vez que hagas un pull.
No creo que el enfoque de enlace simbólico hubiera funcionado, según he encontrado a personas discutiendo no hace mucho tiempo por qué no funciona. He hecho una solicitud de extracción que debería solucionar esto aprovechando los flujos de trabajo reutilizables.
No. Definitivamente no, pero pensé (¿pienso?) que los enlaces duros sí lo harán.
Sí. Creo que la solución de enlaces duros podría funcionar. Creo que puedo enlazar desde el repositorio esqueleto a los otros y luego hago un git pull en el esqueleto y entonces todos los archivos enlazados a esos obtendrán la nueva versión, y no creo que git se dé cuenta de que varios archivos están enlazados allí.
Y ahora hay una nueva idea que no entiendo del todo… [edit] pero ahora casi la entiendo. . .
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.