search

hotsh / rstat.us

Simple microblogging network based on the ostatus protocol.
http://rstat.us/
Other
722 stars 215 forks source link

Use newer Ruby version file standard supported by rbenv and rvm #773

Closed mathias closed 10 years ago

mathias commented 11 years ago

To quote Lumpy Space Princess:

LSP

wilkie commented 11 years ago

what's 'bwstatus'? I think to fit the behavior of the rvmrc, the gemset should be the same: "rstatus"

mathias commented 11 years ago

GAH. that's totally my local config leaking through. Sorry about that.

mathias commented 11 years ago

Fixed in e01801d1b45df51acb07a323aba8c29f17d5d8c3.

mathias commented 11 years ago

Why are the tests running against 1.9.2 on Travis?

tgraham commented 11 years ago

1.9.2 is specified in .travis.yml is the why, why it's in .travis.yml, I dunno.

Travis

On Aug 29, 2013, at 10:44 AM, Matt Gauger notifications@github.com wrote:

Why are the tests running against 1.9.2 on Travis?

— Reply to this email directly or view it on GitHub.

tgraham commented 11 years ago

Checking the history, 1.9.2 was part of the original Travis setup (Aug 2011) before 1.9.3p0 was released (Oct 2011) and just hasn't been removed since.

Best thought is that there are probably still old installs running on 1.9.2 and it's for regression testing so as not to break things. Only recently was 1.9.3 specified in the Gemfile (yesterday to fix Heroku's default 2.0 problems with new deploys of rstatus to Heroku).

Travis

On Aug 29, 2013, at 10:44 AM, Matt Gauger notifications@github.com wrote:

Why are the tests running against 1.9.2 on Travis?

— Reply to this email directly or view it on GitHub.

carols10cents commented 11 years ago

Uggghhhh. And travis is failing because the Gemfile now says 1.9.3.

Are people really dropping 1.9.2 support? I'd like to keep supporting it for a while since it's not very different from 1.9.3...

I'd love to start running travis against 2.0.0 (and allowing it to fail for now) but that's going to mean doing something fancy to the Gemfile, isn't it...

wilkie commented 11 years ago

We should probably tell travis to run builds against 1.9.2, 1.9.3 and 2.0.0 as we should make a point to test with typical deployment environments. We should basically start adopting the same testing-suite-hell a library would use.

That said, a library wouldn't specify the ruby version in the Gemfile... which counters what Heroku wants. Argh. It is like nobody thought that an application may actually want flexible deployment options upon fork! We can add something weird to the Gemfile to get around this maybe.

Can anybody think of a project that might already do this?

jrgifford commented 11 years ago

Discourse maybe?

wilkie commented 11 years ago

Good call.

https://github.com/discourse/discourse

They don't seem to specify their ruby version in their Gemfile and they test on multiple ruby versions in their .travis.yml. The rest of their dot-file stuff is a mess I'll have to go through a little more.

krainboltgreene commented 11 years ago

Most people specify their gemset ruby for Heroku, because that's where it reads from.

Discourse isn't focusing on heroku deployment and thus doesn't have one in the Gemfile.

krainboltgreene commented 11 years ago

As noted here we can make Travis look at a Gemfile that isn't specifying a Ruby, but still ship one that is for heroku sake.

wilkie commented 11 years ago

Discourse seems to be interested in the same things as us... deployment everywhere. It does have a .env.sample and a procfile, so I think discourse should deploy on heroku just fine with the exception of the ruby version in the gemfile. https://shcatula.wordpress.com/2013/07/08/deploying-discourse-to-heroku/ <-- This person has a bash script to add that to the Gemfile.

We can't force a ruby version anyway, just like discourse can't... so we need better options, for instance detecting heroku in the Gemfile somehow.

Or we can just go and ping @dominic and ask "How does one specify a default ruby version that won't conflict with deployment elsewhere including integration testing? That is, how can we get around having to specify the ruby version in the Gemfile?" The answer might just be "Write a darned deployment script / gem already."

krainboltgreene commented 11 years ago

This should fix the build: https://github.com/mathias/rstat.us/pull/1

mathias commented 11 years ago

Do we take the ruby version out of the Gemfile in mathias/rstat.us#1 or does it stay?

mathias commented 11 years ago

Travis still seems unhappy about the ruby version in the Gemfile.

mathias commented 11 years ago

The other option is just to use the travis env variable and ignore the ruby line if we're on Travis; that seems simpler than maintaining multiple Gemfiles.

I'll push a commit to that effect and we'll see what happens.

mathias commented 11 years ago

This looks good. Anyone want to take a second look and OK it?

mathias commented 10 years ago

Closing due to inactivity.