Tentando enviar um plugin, estou recebendo esta falha ao descompactar o redis.
Talvez --long=30 seja o problema? Não estou muito claro sobre como tentar depurar isso…
1 curtida
Eu acho que o erro está dizendo que não pode executar zstd. Você tem esse pacote instalado?
Não. Talvez algo tenha mudado na imagem base do Docker, ou no SO com o qual ela é criada e precise ser adicionado lá. Eu realmente não tenho certeza de onde isso deveria acontecer, mas tenho quase certeza de que não está no meu plugin. 
O requisito zstd vem do pacote do redis (baixado na sua captura de tela) sendo compactado por zstd. Se zstd não era necessário antes, potencialmente o método de compactação mudou no lado de shogo82148/actions-setup-redis.
1 curtida
Se você estiver usando nossa imagem base, não deverá configurar nenhum Redis, pois ele já está lá.
Eu sempre tento fazer tudo do seu jeito. 
Estou usando a imagem base e o processo descrito em:
Funcionou na semana passada. Não há um novo commit nesses fluxos de trabalho em 2 meses. Não acho que haja algo que eu possa ter feito no meu plugin para quebrar isso dessa maneira específica.
Esse processo foi atualizado em 15 de setembro para remover essa ação do Redis, não foi?
1 curtida
É isso! Existe alguma maneira recomendada/fácil de evitar que isso aconteça e parecer tão tolo?
1 curtida
Não tenho certeza, para ser honesto 
A eterna luta entre esses projetos esqueléticos e atualizações contínuas é bastante comum, e embora possam ser resolvidas com alguma composição de arquivos de configuração em alguns lugares, às vezes você ainda precisará compará-los manualmente.
É um problema constante na minha distribuição Linux atual, então me identifico.
1 curtida
Ha! Pelo menos estou em boa companhia. Isso é uma grande ajuda.
Sim. Foram cerca de 15 minutos hoje descobrindo como atualizar o node.js.
1 curtida
Não estou familiarizado com os processos envolvidos no uso desse projeto esqueleto, mas você poderia usar aliases de shell? Por exemplo, em vez de usar docker whizzy things, treine-se para usar seu próprio alias, como alias dwt="git pull; docker whizzy things"
Infelizmente, não. Uma solução improvisada maluca poderia envolver links rígidos entre meu plugin e o plugin esqueleto e alguma forma automatizada de puxar os últimos commits do esqueleto. Receio que a solução de “esperar até que quebre e lembrar de verificar os fluxos de trabalho do GitHub” seja o caminho a seguir.
Obrigado.
Se eu estiver interpretando corretamente, acho que você provavelmente tem uma cópia do projeto esqueleto (com todas as coisas importantes substituídas pela sua própria mágica de plugin) e o problema é que os arquivos de fluxo de trabalho nessa cópia ficam desatualizados.
Você poderia adicionar o repositório esqueleto como um submódulo e, em seguida, substituir os arquivos de fluxo de trabalho em seu repositório por links simbólicos para o submódulo? Definir git config submodule.recurse true manterá o submódulo atualizado sempre que você fizer um pull.
Não acho que a abordagem de symlink teria funcionado, com base em algumas pessoas discutindo recentemente por que ela não funciona. Fiz um pull request que deve resolver isso aproveitando os fluxos de trabalho reutilizáveis.
Não. Definitivamente não, mas pensei (acho?) que os hard links funcionariam.
Sim. Acho que a solução de hard link pode funcionar. Acho que posso fazer um hard link do repositório esqueleto para os outros e então eu faço um git pull no esqueleto e todos os arquivos vinculados a eles receberão a nova versão, e acho que o git não notará que vários arquivos estão vinculados lá.
E agora há uma nova ideia que eu não entendo bem…[edit]mas agora eu quase entendo. . .
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.