플러그인을 제출하려고 하는데, redis를 언타르하는 과정에서 이 실패가 발생합니다.
아마도 --long=30이 문제일까요? 어떻게 디버깅을 시도해야 할지 잘 모르겠습니다…
오류가 zstd를 실행할 수 없다는 것을 의미하는 것 같습니다. 해당 패키지가 설치되어 있나요?
아니요. 아마도 기본 Docker 이미지나 그로 생성되는 OS에서 무언가가 변경되어, 해당 항목을 거기에 추가해야 하는 것일 수 있습니다. 정확히 어디서 처리해야 하는지는 확신이 서지 않지만, 제 플러그인 쪽이 아니라는 점은 꽤 확신합니다. 
zstd 요구 사항은 스크린샷에서 확인된 것처럼 zstd로 압축된 redis 패키지(다운로드됨)에서 비롯됩니다. 이전에 zstd가 필요하지 않았다면, shogo82148/actions-setup-redis 측에서 압축 방식이 변경되었을 가능성이 있습니다.
저희 기본 이미지를 사용 중이라면 Redis를 별도로 설정할 필요가 없습니다. 이미 이미지에 포함되어 있기 때문입니다.
항상 말씀하신 대로 진행하려고 노력합니다. 
다음에 설명된 기본 이미지와 프로세스를 사용하고 있습니다:
지난주까지는 잘 작동했습니다. 해당 워크플로우에는 2개월 동안 새로운 커밋이 없습니다. 제 플러그인에서 이 특정 방식으로 문제를 일으킬 수 있는 것이 있다고 생각되지 않습니다.
해당 프로세스는 9월 15일에 업데이트되어 그 Redis 동작이 제거되었던 것 아닌가요?
그렇다면요! 이런 일이 일어나지 않고 어색해 보이지 않도록 하는 추천하거나 쉬운 방법이 있을까요?
솔직히 잘 모르겠어요 
이런 스켈레톤 프로젝트와 지속적인 업데이트 사이의 영원한 갈등은 꽤 흔한 일이에요. 일부에서는 구성 파일 조합으로 해결할 수 있지만, 때로는 여전히 수동으로 diff를 확인해야 합니다.
제가 현재 사용하는 리눅스 디스트로에서도 늘 발생하는 문제라, 그 마음 충분히 이해합니다.
하! 적어도 좋은 동료들이 있네요. 정말 큰 도움이 됩니다.
네. 오늘 node.js 업그레이드 방법을 알아내는 데 15분이나 걸렸거든요.
그 스켈레톤 프로젝트를 사용하는 과정에 대해서는 잘 모르겠지만, 셸 별명을 활용할 수 있을까요? 예를 들어 docker whizzy things 대신, alias dwt="git pull; docker whizzy things"와 같은 사용자 지정 별명을 사용하도록 훈련하는 것입니다.
아쉽게도, 아닙니다. 제 플러그인과 스켈레톤 플러그인 사이에 하드 링크를 만들고 스켈레톤의 최신 커밋을 자동으로 가져오는 방식 같은 미친 해킹이 필요할 수도 있겠네요. "깨질 때까지 기다렸다가 GitHub 워크플로우를 확인하는 걸 잊지 말자"는 해결책이 최선의 방법인 것 같습니다.
감사합니다.
제가 올바르게 이해했다면, 스켈레톤 프로젝트의 복사본(중요한 부분들은 모두 자체 플러그인으로 대체된 상태)을 가지고 계신 것 같고, 문제는 그 복사본 안의 워크플로 파일들이 최신 버전이 아닌 구버전으로 남아있게 된다는 점인 것 같습니다.
스켈레톤 저장소를 서브모듈로 추가한 후, 현재 저장소의 워크플로 파일을 서브모듈로 향하는 심볼릭 링크로 대체해 보시는 건 어떨까요? git config submodule.recurse true를 설정해 두면, pull을 할 때마다 서브모듈이 자동으로 업데이트됩니다.
일부 사람들이 비교적 최근에 심볼릭 링크 방식이 작동하지 않는 이유에 대해 논의하는 것을 확인했기 때문에, 해당 접근 방식이 작동했을 것이라고 생각하지 않습니다. 재사용 가능한 워크플로우를 활용하여 이 문제를 해결할 수 있도록 풀 리퀘스트를 생성했습니다.
아니요. 확실히 그렇습니다. 하지만 하드링크는 작동할 것 같다고 생각했어요(아직도 그렇게 생각합니까?).
네. 하드링크 솔루션이 실제로 작동할 것 같습니다. 스켈레톤 저장소에서 다른 저장소들로 하드링크를 걸고, 스켈레톤에서 git pull을 하면 그 파일들에 연결된 모든 파일이 새 버전으로 업데이트될 것 같고, git가 여러 파일이 그곳에서 연결되어 있다는 것을 알아차리지 못할 것 같습니다.
그리고 이제 제가 완전히 이해하지는 못하는 새로운 아이디어가 생겼습니다…[edit]하지만 이제 거의 이해하고 있습니다…