Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

'bundle exec jekyll server -w -s _source -d _site' does not work for ruby 2.2.0 #8

Closed
GrantPax opened this issue Jan 17, 2015 · 30 comments
Closed

'bundle exec jekyll server -w -s _source -d _site' does not work for ruby 2.2.0 #8

GrantPax opened this issue Jan 17, 2015 · 30 comments

Comments

@GrantPax
Copy link
Contributor

I tried 2.2.0 and it failed. 2.1.4 works.

$ rvm use 2.2.0
Using /usr/local/rvm/gems/ruby-2.2.0
$ bundle exec jekyll server -w -s _source -d _site
/usr/local/rvm/gems/ruby-2.2.0/gems/safe_yaml-1.0.3/lib/safe_yaml/load.rb:43:in <module:SafeYAML>': undefined methodtagged_classes' for Psych:Module (NoMethodError)
from /usr/local/rvm/gems/ruby-2.2.0/gems/safe_yaml-1.0.3/lib/safe_yaml/load.rb:26:in <top (required)>' from /usr/local/rvm/gems/ruby-2.2.0/gems/jekyll-2.0.3/lib/jekyll.rb:21:inrequire'
from /usr/local/rvm/gems/ruby-2.2.0/gems/jekyll-2.0.3/lib/jekyll.rb:21:in <top (required)>' from /usr/local/rvm/gems/ruby-2.2.0/gems/jekyll-2.0.3/bin/jekyll:6:inrequire'
from /usr/local/rvm/gems/ruby-2.2.0/gems/jekyll-2.0.3/bin/jekyll:6:in <top (required)>' from /usr/local/rvm/gems/ruby-2.2.0/bin/jekyll:23:inload'
from /usr/local/rvm/gems/ruby-2.2.0/bin/jekyll:23:in <main>' from /usr/local/rvm/gems/ruby-2.2.0/bin/ruby_executable_hooks:15:ineval'
from /usr/local/rvm/gems/ruby-2.2.0/bin/ruby_executable_hooks:15:in `

'
$ rvm use 2.1.4
Using /usr/local/rvm/gems/ruby-2.1.4
$ bundle exec jekyll server -w -s _source -d _site
Configuration file: _source/_config.yml
Source: _source
Destination: _site
Generating...
done.
Auto-regeneration: enabled
Configuration file: _source/_config.yml
Server address: http://0.0.0.0:4000/
Server running... press ctrl-c to stop.
@GrantPax
Copy link
Contributor Author

It's a known (at least debated) issue with ruby. I'd be happy to add a "recommended version" statement to README.md if that would help. Could it be specific to Mac (my platform)? I don't know.

@bjhargrave
Copy link
Member

This seems like a jekyll dependency. We really need to move this over to the normal GitHub Pages flow. We went the current route because @pkriens needed jekyll 2 features and, at the time, GitHub Pages only used jekyll 1.

@GrantPax
Copy link
Contributor Author

Let me know if I can help?

@bjhargrave
Copy link
Member

Let me know if I can help?

Well if you have any skills with GitHub Pages, please take a crack at converting this away from the current model where we build on travis and push to built pages back to the vanilla GitHub Pages model. I tried once on https://github.com/bndtools/bnd.manual which uses the same build but my fu was not enough.

@bjhargrave
Copy link
Member

I tried 2.2.0 and it failed. 2.1.4 works.

See https://github.com/osgi/osgi.enroute.site/blob/master/.travis.yml#L3 which declares 2.0 as the required ruby to build the site.

@GrantPax
Copy link
Contributor Author

I didn't know to look at the travis.yml file. Sorry.

I am fu-less on GitHub pages. I'll see what I can do.

@GrantPax
Copy link
Contributor Author

I'll report back on my progress tomorrow unless you need to hear sooner.

@bjhargrave
Copy link
Member

No rush. @pkriens and I will be at OSGi meetings next week anyway. So we probably will have little spare time...

@GrantPax
Copy link
Contributor Author

I have spent hours on this one hoping to knock it out. I used the Gemfile from jekyll that is designed to install exactly what Github specifies. Fresh jekyll project (jekyll new .). I added or changed nothing myself and here's what we get (below). Running locally and running on GitHub. I don't see how it can be anything but a Github rendering issue. I'm trying to figure out how to debug their render. Truly fu-less. Here's the repo if you are at all interested.

screen shot 2015-01-17 at 11 16 16 pm
screen shot 2015-01-17 at 11 16 34 pm

@GrantPax
Copy link
Contributor Author

resetting the branch didn't help - same result
checkout gh-pages ; git push origin --delete gh-pages ; git push origin

@GrantPax
Copy link
Contributor Author

I'm looking for a snipe

@GrantPax
Copy link
Contributor Author

I've opened an issue with the pages guys: github/pages-gem#114. I'm packing it in for the night.

@GrantPax
Copy link
Contributor Author

OK. The pages guys found the issue. I now get consistent results from a fresh Jekyll install. I am testing basic edits.

What seems to make sense to me is to incrementally add the osgi.enroute.site content to this working repo, testing all the way up. I'm not sure what to do once I get it all working. I guess we'll see when I get there. Please stop me if I should head another way.

@pkriens
Copy link
Member

pkriens commented Jan 18, 2015

Ehhh. Since Github pages did not support Jekyll 2.+ at the time I could not use Github page as is. I just installed Jekyll 2.from their site and that worked fine. Remember that all those bundles and gem files were a pain in the ass as well.

Then in the master branch you make changes. If you commit, we build on travis and push gh-pages which are then without any further Jekyll help displayed as html.

To verify locally you use (cwd = root of master branch)

jekyll server -w -s _source -d _site

Post 4000 then on localhost shows you the local mapping.

@GrantPax
Copy link
Contributor Author

Yup. I understand that process. BJ was talking about getting out of the Travis build business. I have a repo that GitHub builds consistently and was going to migrate/reconfigure the current content so Travis is out of the loop. Would you like me to work in that direction or leave as is? I have an issue open (GrantPax/osgi.enroute.site.gh-pages#1 GrantPax/osgi.enroute.site.gh-pages#1) and was going to document work there. I’ll stop if you’d rather I work somewhere else.

On Jan 18, 2015, at 2:58 PM, Peter Kriens notifications@github.com wrote:

Ehhh. Since Github pages did not support Jekyll 2.+ at the time I could not use Github page as is. I just installed Jekyll 2.from their site and that worked fine. Remember that all those bundles and gem files were a pain in the ass as well.

Then in the master branch you make changes. If you commit, we build on travis and push gh-pages which are then without any further Jekyll help displayed as html.

To verify locally you use (cwd = root of master branch)

jekyll server -w -s _source -d _site

Post 4000 then on localhost shows you the local mapping.

—
Reply to this email directly or view it on GitHub #8 (comment).

@bjhargrave
Copy link
Member

I want to pursue using normal github pages. I'll talk with @pkriens this week to make sure he is in agreement.

@GrantPax
Copy link
Contributor Author

Thanks for the feedback. I will proceed until I hear otherwise.

On Jan 18, 2015, at 3:56 PM, BJ Hargrave notifications@github.com wrote:

I want to pursue using normal github pages. I'll talk with @pkriens https://github.com/pkriens this week to make sure he is in agreement.

—
Reply to this email directly or view it on GitHub #8 (comment).

@GrantPax
Copy link
Contributor Author

OK. After some heads down, I have a Travis-less, all-GitHub repo working here. Most of the trouble came from pathing issues with a smattering of other stuff. There's more to do (like the ends of the next<-->previous navigation are still broken). I made some notes on the work here: GrantPax/osgi.enroute.site.gh-pages#1. I have created a few other issues that need to be addressed both sooner and later. I will continue that logging process as appropriate.

If you like what you see (so far), we have to decide what's next. I'm not git-smart enough to know how to apply all the changes I made to my from-scratch repo in any automated way. I don't know how important the history is to you. If you really, really need the history, I'll figure out how to fix the existing repo using what I've learned from this process. My only concern there is the threat of enroute.osgi.org being down for one reason or another.

I'll keep cleaning up and continue working through the tutorials and examples, modifying my new repo - unless you tell me to do differently.

@pkriens
Copy link
Member

pkriens commented Jan 19, 2015

I’d rather keep it working as it is. I am using some advanced features of Jekyll and noticed that Github was rather slow in picking it up. Anyway, it works and there is more than enough work on things that don’t work :-)

Kind regards,

Peter Kriens

On 18 jan. 2015, at 21:38, Grant Pax notifications@github.com wrote:

Yup. I understand that process. BJ was talking about getting out of the Travis build business. I have a repo that GitHub builds consistently and was going to migrate/reconfigure the current content so Travis is out of the loop. Would you like me to work in that direction or leave as is? I have an issue open (GrantPax/osgi.enroute.site.gh-pages#1 GrantPax/osgi.enroute.site.gh-pages#1) and was going to document work there. I’ll stop if you’d rather I work somewhere else.

On Jan 18, 2015, at 2:58 PM, Peter Kriens notifications@github.com wrote:

Ehhh. Since Github pages did not support Jekyll 2.+ at the time I could not use Github page as is. I just installed Jekyll 2.from their site and that worked fine. Remember that all those bundles and gem files were a pain in the ass as well.

Then in the master branch you make changes. If you commit, we build on travis and push gh-pages which are then without any further Jekyll help displayed as html.

To verify locally you use (cwd = root of master branch)

jekyll server -w -s _source -d _site

Post 4000 then on localhost shows you the local mapping.

—
Reply to this email directly or view it on GitHub #8 (comment).

—
Reply to this email directly or view it on GitHub #8 (comment).

@GrantPax
Copy link
Contributor Author

Either way is fine with me. As I said, I have the site working without Travis with the exception of a minor bug or two. I'll probably have those squashed today. I haven't noticed any build lag from GitHub — and maybe I'm missing something. Again, either way.

I'd hate to be the point of some contention. I'm just looking to be helpful. Please accept my apologies if I somehow messed something up.

@GrantPax
Copy link
Contributor Author

Ok. With no disrespect for Peter's desire to use the current configuration or other innuendo, the migration to a GitHub-only build is complete. I only finished it off because I was almost there by the time Peter voiced a preference to the contrary. The reconfigured repo can be used or not. It's entirely up to you.

I'm off to work on the tutorial.

@GrantPax
Copy link
Contributor Author

Oops. Forgot. If someone does decide to use the GitHub-only version, the necessary configuration is outlined in the CONFIGURATION.md file in the meta-config branch.

@bjhargrave
Copy link
Member

Thanks. I talked with Peter and he is ok with proceeding with this but I won't be able to look at your work until next week when I get back from my trip.

@GrantPax
Copy link
Contributor Author

That works. I hope it helps. Until you have a chance to review, I will duplicate my edits to keep the content of both repos in sync in case something doesn’t work out.

I hope your trip is fruitful. Please give Peter my regards.

On Jan 20, 2015, at 10:15 AM, BJ Hargrave notifications@github.com wrote:

Thanks. I talked with Peter and he is ok with proceeding with this but I won't be able to look at your work until next week when I get back from my trip.

—
Reply to this email directly or view it on GitHub #8 (comment).

@GrantPax
Copy link
Contributor Author

Given that all meaningful work has to end up in the gh-pages branch, we'll have to decide what to do with the master branch. I'd recommend deleting it. Once/If we cutover, we can delete the meta-config branch too.

@bjhargrave
Copy link
Member

I looked at your repo but the changes were too many and I did not see many of them as necessary. For example, you added base_url everywhere which is not needed on the actual website but only due to the way you were testing.

But after looking at your changes, I realized I could easily do the change and preserve the history. So I made commit 32b17a3 which converted the site over to github pages. It took a few more commits to get the travis as a test builder for PRs working right but all seems good now.

The main think I learned from your work was the Gemfile. Thanks for finding that. It was the key to making the change easy. The rest was just moving files from _source => / and some other doc and script edits.

@GrantPax
Copy link
Contributor Author

Per the 4th comment on my initial issue, I simply could not get the GitHub render to work without the base_url. You clearly have fu I don't. The base_url did indeed make for too many changes. For what it's worth, here is the GitHub pages issue where the gh-pages gem guys told me to set the base_url. So much for that. My fu-lessness hasn't changed.

I'm glad the Gemfile helped at least.

@GrantPax
Copy link
Contributor Author

Oh. This is the testing issue to which you were referring: jekyll/jekyll#332. I see. I wish I had understood that.

@bjhargrave
Copy link
Member

You had it set up as a project site rather than a user site which is why you needed the baseurl.

@GrantPax
Copy link
Contributor Author

Education is expensive. Thanks.

On Jan 27, 2015, at 7:08 PM, BJ Hargrave notifications@github.com wrote:

You had it set up as a project site rather than a user site which is why you needed the baseurl.

—
Reply to this email directly or view it on GitHub #8 (comment).

claudiob added a commit to claudiob/rails.github.com that referenced this issue May 3, 2015
@claudiob
Update Jekyll to run with Ruby 2.2
a540aa2 
Running ruby 2.2.2p95 on my machine, I was not able to start the
application locally: `jekyll --server` would return this error:

```
~/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/commander-4.1.6/lib/commander/runner.rb:385:in `block in require_program': program version required (Commander::Runner::CommandError)
	from ~/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/commander-4.1.6/lib/commander/runner.rb:384:in `each'
	from ~/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/commander-4.1.6/lib/commander/runner.rb:384:in `require_program'
	from ~/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/commander-4.1.6/lib/commander/runner.rb:52:in `run!'
	from ~/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/commander-4.1.6/lib/commander/delegates.rb:8:in `run!'
	from ~/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/commander-4.1.6/lib/commander/import.rb:10:in `block in <top (required)>'
~/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/safe_yaml-1.0.3/lib/safe_yaml/load.rb:43:in `<module:SafeYAML>': undefined method `tagged_classes' for Psych:Module (NoMethodError)
	from ~/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/safe_yaml-1.0.3/lib/safe_yaml/load.rb:26:in `<top (required)>'
	from ~/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/safe_yaml-1.0.3/lib/safe_yaml.rb:1:in `require'
	from ~/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/safe_yaml-1.0.3/lib/safe_yaml.rb:1:in `<top (required)>'
	from ~/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/jekyll-1.5.1/lib/jekyll.rb:21:in `require'
	from ~/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/jekyll-1.5.1/lib/jekyll.rb:21:in `<top (required)>'
	from ~/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/jekyll-1.5.1/bin/jekyll:7:in `require'
	from ~/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/jekyll-1.5.1/bin/jekyll:7:in `<top (required)>'
	from ~/.rbenv/versions/2.2.2/bin/jekyll:23:in `load'
	from  .rbenv/versions/2.2.2/bin/jekyll:23:in `<main>'
```

I found this to be a known issue (see [this](dtao/safe_yaml#67), [this](http://stackoverflow.com/questions/29245100/github-pages-error-running-jekyll-locally) and [this](osgi/osgi.enroute.site#8)), and was able to start the application by
running `bundle update jekyll`.
@claudiob claudiob mentioned this issue May 3, 2015
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@pkriens @bjhargrave @GrantPax