Sto provando a inviare un plugin, sto ricevendo questo errore durante l’untarring di redis.
Forse --long=30 è il problema? Non mi è chiaro come provare a eseguire il debug di questo…
1 Mi Piace
Penso che l’errore dica che non può eseguire zstd. Hai quel pacchetto installato?
No. Forse è cambiato qualcosa nell’immagine Docker di base, o nel sistema operativo con cui è stata creata e deve essere aggiunto lì. Non mi è molto chiaro dove dovrebbe succedere, ma sono abbastanza sicuro che non sia nel mio plugin. 
Il requisito zstd proviene dal pacchetto redis (scaricato nello screenshot) compresso da zstd. Se zstd non era richiesto prima, potenzialmente il metodo di compressione è cambiato dal lato di shogo82148/actions-setup-redis.
1 Mi Piace
Se stai usando la nostra immagine di base, non dovresti configurare alcun Redis, poiché è già presente.
Cerco sempre di fare tutto a modo vostro. 
Sto usando l’immagine di base e il processo descritti in:
Ha funzionato la scorsa settimana. Non ci sono nuovi commit in quei flussi di lavoro da 2 mesi. Non credo ci sia qualcosa che avrei potuto fare nel mio plugin per romperlo in questo particolare modo.
Quel processo è stato aggiornato il 15 settembre per rimuovere quell’azione Redis, non è vero?
1 Mi Piace
È tutto! C’è un modo consigliato/facile per evitare che ciò accada e sembrare così sciocco?
1 Mi Piace
Non sono sicuro, a dire il vero 
L’eterna lotta tra quei progetti scheletrici e gli aggiornamenti continui è piuttosto comune, e mentre possono essere risolti con una composizione di file di configurazione in alcuni punti, a volte avrai comunque bisogno di confrontarli manualmente.
È un problema costante nella mia attuale distribuzione Linux, quindi ti capisco.
1 Mi Piace
Ah! Almeno sono in buona compagnia. È un grande aiuto.
Sì. Oggi ci sono voluti circa 15 minuti per capire come aggiornare node.js.
1 Mi Piace
Non ho familiarità con i processi coinvolti nell’utilizzo di quel progetto scheletro, ma potresti sfruttare gli alias della shell in qualche modo? Ad esempio, invece di usare docker whizzy things, allenati a usare il tuo alias come alias dwt="git pull; docker whizzy things"
Purtroppo no. Un hack folle potrebbe comportare collegamenti fisici tra il mio plugin e il plugin scheletro e un qualche modo automatizzato per recuperare gli ultimi commit dallo scheletro. Temo che la soluzione “aspetta che si rompa e ricorda di controllare i workflow di GitHub” sia la strada da percorrere.
Grazie.
Se interpreto correttamente, penso che tu abbia una copia del progetto scheletro (con tutte le cose importanti sostituite dalla tua magia di plugin) e il problema è che i file di flusso di lavoro in quella copia diventano obsoleti.
Potresti aggiungere il repository scheletro come sottomodulo e quindi sostituire i file di flusso di lavoro nel tuo repository con collegamenti simbolici nel sottomodulo? Impostare git config submodule.recurse true manterrà il sottomodulo aggiornato ogni volta che esegui un pull.
Non credo che l’approccio del symlink avrebbe funzionato, basandomi su alcune discussioni recenti sul perché non funzioni. Ho creato una pull request che dovrebbe risolvere questo problema sfruttando i flussi di lavoro riutilizzabili.
No. Decisamente no, ma pensavo (penso?) che i collegamenti fisici funzioneranno.
Sì. Penso che la soluzione dei collegamenti fisici potrebbe funzionare. Penso di poter creare collegamenti fisici dal repository scheletro agli altri e poi fare un git pull sullo scheletro e quindi tutti i file collegati a quelli riceveranno la nuova versione, e non credo che git noterà che più file sono collegati lì.
E ora c’è una nuova idea che non capisco del tutto… [edit] ma ora quasi la capisco…
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.