Tests at github actions fail set up redis

Trying to submit a plugin, I’m getting this failure on untarring redis.

Maybe --long=30 is the issue? I’m not quite clear how to try to debug this…

1 Like

I think the error is saying that it can’t execute zstd. Do you have that package installed?

No. Perhaps something changed in the base Docker image, or the OS that it’s created with and it needs to be added there. I’m really not clear where that should happen, but I’m pretty sure that it’s not in my plugin. :man_shrugging:

The zstd requirement is coming from the redis package (downloaded in your screenshot) being compressed by zstd. If zstd wasn’t required before, potentially the compression method changed on the shogo82148/actions-setup-redis side.

1 Like

If you are using our base image, you shouldn’t set up any Redis, as it’s already there.

I always try to do everything your way. :wink:

I’m using the base image and process described in:

It worked last week. There isn’t a new commit in those workflows in 2 months. I don’t think there’s anything that I could have done in my plugin to break this in this particular way.

That process was updated Sept 15th to remove that Redis action, wasn’t ?

1 Like

That’s it! Is there some recommended/easy way to not let this happen and look so foolish?

1 Like

Not sure to be honest :grinning_face_with_smiling_eyes:

The eternal struggle between those skeleton projects and continuous updates are quite common, and while they can be solved by some configuration file composition in some places, sometimes you will still need to manually diff it.

It’s a constant problem in my current linux distro flavor, so I feel you.

1 Like

Ha! At least I’m in good company. That’s a huge help.

Yeah. That was about 15 minutes today figuring out how to upgrade node.js.

1 Like

I’m not familiar with the processes involved with using that skeleton project but could you leverage shell aliases at all? E.g. instead of using docker whizzy things, train yourself to use your own alias such as alias dwt="git pull; docker whizzy things"

Sadly, no. A crazy hack might involve hard links between my plugin and the skeleton plugin and some automated way to pull in the latest commits on the skeleton. I’m afraid the “wait until it breaks and remember to check the github workflows” solution is the way to go.


If I’m interpreting it correctly, I think you probably have a copy of the skeleton project (with all the important stuff replaced with your own plugin magic) and the issue is that the workflow files in that copy become out-of-date.

Could you add the skeleton repository as a submodule and then replace the workflow files in your repository with symlinks into the submodule? Setting git config submodule.recurse true will keep the submodule updated whenever you do a pull.

I don’t think the symlink approach would have worked based on finding some people semi-recently discussing why it doesn’t work. I’ve made a pull request which should deal with this by taking advantage of reusable workflows.

No. Definitely not, but I thought (think?) that hard links will.

Yeah. I think that the hard-link solution might just work. I think that I can hard link from the skeleton repo to the others and then I do a git pull on the skeleton and then all files linked to those will get the new version, and I don’t think that git will notice that multiple files are linked there.

And now there’s a new idea that I don’t quite understand…[edit]but now I almost do. . .

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.