win10, jekyll/jeykll:pages build error with commonmarker

[robgrzel]

Hi!
When I do: docker-compose up
for docker-compose.yml:
jekyll:
image: jekyll/jekyll:pages
command: jekyll serve --watch --incremental
ports:
- 4000:4000
volumes:
- .:/srv/jekyll

I get error:

Fetching commonmarker 0.17.7.1
Installing commonmarker 0.17.7.1 with native extensions
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

current directory: /usr/local/bundle/gems/commonmarker-0.17.7.1/ext/commonmarker
/usr/local/bin/ruby -r ./siteconf20171227-34-8zulf2.rb extconf.rb
creating Makefile

current directory: /usr/local/bundle/gems/commonmarker-0.17.7.1/ext/commonmarker
make "DESTDIR=" clean
sh: make: not found

current directory: /usr/local/bundle/gems/commonmarker-0.17.7.1/ext/commonmarker
make "DESTDIR="
sh: make: not found

make failed, exit code 127

Gem files will remain installed in /usr/local/bundle/gems/commonmarker-0.17.7.1 for inspection.
Results logged to /usr/local/bundle/extensions/x86_64-linux/2.5.0/commonmarker-0.17.7.1/gem_make.out

An error occurred while installing commonmarker (0.17.7.1), and Bundler cannot continue.
Make sure that gem install commonmarker -v '0.17.7.1' succeeds before bundling.

In Gemfile:
github-pages was resolved to 172, which depends on
jekyll-commonmark-ghpages was resolved to 0.1.3, which depends on
jekyll-commonmark was resolved to 1.1.0, which depends on
commonmarker

[envygeeks]

This can happen if your Gemfile.lock is out of sync with the version of Jekyll we provide, or you provide a version of Jekyll that doesn't match ours inside of your Gemfile, or if you include extra gems that Github Pages doesn't support. We do not support compiling gems on the pages tag, even if you are trying to update, match, or otherwise, custom is custom to this image.

You can fix this by double checking your Gemfile, and removing your Gemfile.lock which should fix this problem. If it does not please do update this ticket and provide more information about your setup, because a log without context provides us no help with figuring out why your build is behaving like that.

[simonis]

Hi,
I did run into exactly the same problem on Ubuntu 14. I did the following:

$ docker pull jekyll/jekyll:pages
$ docker run -v `pwd`:/srv/jekyll -p 4000:4000 jekyll/jekyll:pages jekyll serve --watch --incremental

In the current directory from where I did run the docker command I have the following files:

$ ls 
_config.yml  Gemfile  index.md
$ cat Gemfile 
source 'https://rubygems.org'
gem 'github-pages', group: :jekyll_plugins
gem "jekyll-theme-cayman"

This seems very basic. Do you have any idea, why github-pages transitively requires commonmarker which requires native compilation. Is this a new dependency?

Do you have any advice how to workaround this?

Thanks a lot and best regards,
Volker

[envygeeks]

I don't work for Github, you would have to ask them why they are doing something new suddenly.

[envygeeks]

My only suggestion is to stop using the pages tag and use the regular tag, which will let you compile, as we do not remove development dependencies in regular tags.

[simonis]

I can confirm that it works perfectly with jekyll/jekyll:latest.

I understand that you're not working for Github, but what sense does it make to provide an image version tagged pages which from my understanding is intended for running Github pages, if it is not working?

Anyway, thanks a lot for providing the jekyll containers. They still helped me a lot!

[envygeeks]

I understand that you're not working for Github, but what sense does it make to provide an image version tagged pages which from my understanding is intended for running Github pages, if it is not working?

And just like Github's pages, you aren't supposed to supply a Gemfile, and if you do, and we can detect a discrepancy, you trigger the logic meant for other images that tries to ensure that your builds will work. It's well established this happens (years worth of establishment,) and on top of that, it's well noted that we do not provide compiling dependencies on pages, because of this fact. So if you provide a Gemfile, instead of just doing docker run with your Jekyll source, without a Gemfile, it's at your own peril and not considered a bug on our end.

[simonis]

Thanks a lot for your detailed explanation and sorry if my comments are a little blurry - I just started to use Jekyll and GitHub pages yesterday so I'm still trying to figure out how everything fits together.

You're right that even jekyll/jekyll:pages works fine if I remove the Gemfile. On the other hand, I've only added the Gemfile because that's the way the GitHub documentation describes how to set up your github pages locally.

So if you don't mind, can you please confirm if my limited understanding so far is correct? Without Gemfile, my site will be built with all the pre-installed gems in your Docker image. The versions of these Gems my be however different from the exact versions used by GitHub to build my site. If I use a Gemfile as described in the GitHub documentation for setting up my github pages locally, this will trigger the installation (and native build) of all the Gems which differ from the default versions in your image. This installation and building is not supported in the jekyll/jekyll:pages images but only in the default jekyll/jekyll:latest version.

By the way, I think the build error my be rated to the latest change in the GitHub pages gem (github/pages-gem#500) which added a dependency on jekyll-commonmark-ghpages.

Finally I kindly ask you to answer a last question if you're still not tired of me :) If I remove the Gemfile from my site and build it with your jekyll/jekyll:pages image, where does the dependency on the github-metadata gem comes from? I.e. from where does Jekyll know that he needs the github-metadata gem in order to resolve references like site.github.project_tagline from my theme layout. I only have the following settings in my _config.yml:

repository: simonis/cl4cds
theme: jekyll-theme-cayman

but the jekyll-theme-cayman gem doesn't seem to have any dependency on github-metadata?

Thanks a lot for your patience,
Volker

[envygeeks]

jordon@doctor (master #) 🐼 docker run --rm -it jekyll/jekyll:pages bash
bash-4.4# gem list | grep jekyll | grep mark
jekyll-commonmark (1.1.0)
jekyll-commonmark-ghpages (0.1.3)
bash-4.4# gem list | grep github-metadata
jekyll-github-metadata (2.9.4, 2.9.3)

Your problem stems from the Gemfile.lock, not the Gemfile directly.

---

For questions on how to load plugins inside of Jekyll, please refer to their documentation at https://jekyllrb.com, we simply just encapsulate Jekyll into a reusable, and clean environment.

---

My images rebuild daily, automatically, without my intervention, to not only pick up security updates, but to pick up new dependencies without me having to lock them, so if Github changed something in their Gem, I would have picked up by 9:00PM that night on the next build, and it would have been available, as shown above.

[surajmandalcell]

You need to install ruby-dev package in addition to the normal ruby installation for this to work

[envygeeks]

I'm pretty sure I know how Ruby works.

[surajmandalcell]

was searching for this issue too, found a solution so i posted it here

[payammeyer]

Installing ruby-dev addressed the issue for me too, so, thanks for that @surajmandalcell.

[gcsalzburg]

To add to the messages installing ruby-dev (or specifically MSYS2 and MINGW development toolchain) fixed the issue for me too.