Running linux-x64-cwebp binary fails in GitHub Actions

[D4D3VD4V3]

I'm using this GitHub action https://github.com/helaili/jekyll-action which enables third-party gems support on GitHub Pages. I can confirm that other third-party gems that I use work fine but this one doesn't. It fails with following error:

WebP: Change to source image file /github/workspace/images/1.jpg detected, regenerating WebP

 WebP: Conversion for image /github/workspace/images/1.jpg failed, no webp version could be created for this image

Using some debug logging statements, I noticed 'Permission denied' errors, but sudo doesn't work either.
From the GitHub Actions docs:

The Linux and macOS virtual machines both run using passwordless sudo. When you need to execute commands or install tools that require more privileges than the current user, you can use sudo without needing to provide a password.

Any suggestions on how to proceed?

BTW I also had to add require 'date' to the jekyll-webp.gemspec file because it wasn't imported automatically.
Moreover, the gem that is installed via gem install jekyll-webp doesn't seem to work (even locally) which is why I'm pulling the GitHub version of this gem directly.

[xsalazar]

I was also running into this and found a solution. I spun my wheels thinking that the error was saying it couldn't find the binary file or the images. However, the exec command inside the plugin returns a 127 if the binary has missing supported libraries. The root cause here is because the Action you're using uses a stripped down Alpine image as its base which is missing a bunch of standard libraries. You can verify the exit code by passing in JEKYLL_DEBUG: true to the Action.

It's a little hacky right now, but you can see my fork of helaili's Actions here: https://github.com/xsalazar/jekyll-action

The change to the Dockerfile is here and just uses an Ubuntu base and installs some dependencies. It's slower, but not a huge deal if you're not looking for instant(ish) builds.

[D4D3VD4V3]

Thank you @xsalazar , that does work! It would be nice if this could be pushed upstream as well.

[datapolitical]

Thanks for finding this! I'm having the same error but I don't have a Dockerfile as part of my workflow. I tried using yours (subtracking the last two lines) with

container:
image: 'Dockerfile'

but it didn't like that. I assume it's some simple copying of your setup steps into my workflow, but the documentation on how to do that isn't great.

How do I incorporate your changes without switching everything up? Here's my workflow: https://github.com/datapolitical/chrisfnicholson.github.io/blob/main/.github/workflows/build-jekyll.yml

I was also running into this and found a solution. I spun my wheels thinking that the error was saying it couldn't find the binary file or the images. However, the exec command inside the plugin returns a 127 if the binary has missing supported libraries. The root cause here is because the Action you're using uses a stripped down Alpine image as its base which is missing a bunch of standard libraries. You can verify the exit code by passing in JEKYLL_DEBUG: true to the Action.

It's a little hacky right now, but you can see my fork of helaili's Actions here: https://github.com/xsalazar/jekyll-action

The change to the Dockerfile is here and just uses an Ubuntu base and installs some dependencies. It's slower, but not a huge deal if you're not looking for instant(ish) builds.

[xsalazar]

From my understanding, you're saying you're seeing this issue and, looking at your build-jekyll.yml Action, you're using https://github.com/jeffreytse/jekyll-deploy-action to do the deploy? If you look at that repo and checkout what image that Action is using, you'll see it's the stripped down Alpine image: https://github.com/jeffreytse/jekyll-deploy-action/blob/v0.1.4/Dockerfile

Since it looks like you've already built out the inputs for that Action, you could just fork it yourself, change the image, and then point your Action to use your fork.

[datapolitical]

So I’ve tried this but there are differences between alpine and Ubuntu and so I kept hitting errors. (apk vs apt for example). I cut an if statement asking whether I’m using GitHub because it couldn’t parse it correctly and I know I am, and now it’s throwing a “source: not found” error because it can’t figure out the correct location of the file for the next step and I’m at a loss for what wrong.

I think I’ve got the location right, but I’m not sure if it’s that “source” isn’t a thing in Ubuntu or what it means.

Here’s the file where it’s getting stuck on the last line:

https://github.com/datapolitical/jekyll-deploy-action/blob/v0.2.6/entrypoint.sh

I’m sure you’ll spot what’s wrong in a second.

[xsalazar]

@datapolitical I'm not sure off the top of my head, but the filesystem structure might not be what you expect there. It looks like the Dockerfile copies over the provider folder here.

So inside your entrypoint.sh you should just be relative to that root location which would be source "/providers/github.sh" (I think)

[datapolitical]

That was my first attempt. I just figured it out. Turns out it wanted to be run in bash rather than sh, and that fixed the problem.

[datapolitical]

@xsalazar how do you handle caching? I'm now running into an issue where the WebP plugin is re-generating all the assets every time because the deploy-action cleans the gh-pages each time (so I have to solve that). And all the dependencies from your script take a long time to install.

It's not killer but I'd like to not have deployment take 10 minutes every time.

[xsalazar]

I chose to ignore that. My solution is a little hacky and needs to rerun the process twice due to timing issues in the build. It takes a while, but time is not an issue for me.

I would assume this is why the original images use a much smaller, tailored OS. I attempted to get the libraries installed on Alpine, but it quickly spiraled out of control and was just easier to use a base Ubuntu image.

[datapolitical]

That makes sense. I really appreciate your help with this.

[xsalazar]

@datapolitical You got it! ✨