1. 05 Sep, 2017 1 commit
  2. 10 Apr, 2017 1 commit
  3. 21 Mar, 2017 1 commit
  4. 01 Feb, 2017 2 commits
  5. 23 Dec, 2016 1 commit
  6. 04 Aug, 2016 1 commit
  7. 20 Jun, 2016 1 commit
  8. 10 Jun, 2016 1 commit
  9. 08 Jun, 2016 1 commit
  10. 30 May, 2016 1 commit
  11. 17 May, 2016 1 commit
  12. 16 May, 2016 1 commit
  13. 12 May, 2016 2 commits
  14. 09 May, 2016 1 commit
  15. 04 Apr, 2016 1 commit
  16. 22 Mar, 2016 1 commit
    • Lin Jen-Shin's avatar
      Do not use bundler to run foreman, because: · 9501ac70
      Lin Jen-Shin authored
      then the process could be using the Gemfile located on the root
      directory, which only has foreman as the dependency. Later on even if we
      set BUNDLE_GEMFILE to another Gemfile, bundler might have already setup
      and ignore the new BUNDLE_GEMFILE.
      
      Before this patch, I cannot run the application due to missing `rake`,
      but cd into the sub-directory and run from there is running fine.
      With this patch ./run could be running fine as well.
      
      I didn't dig into bundler internal to figure this out, but in my
      experience, messing around BUNDLE_GEMFILE is not a good idea and we
      should try only use bundler for the application, not the wrapping
      script. On the other hand, avoid `bundle exec` and prefer
      `ruby -r bundler/setup` would also reduce the complexity here.
      (avoiding an extra process)
      
      Since foreman is the only dependency in this script, I think there's
      little point to use bundler here even if it works. If we really like to
      specify the version of foreman, we could also run with like:
      `foreman _0.78.0_` or `ruby -S foreman _0.78.0_`, etc. I always use
      this before bundler.
      
      Tested with:
      
      * ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-linux]
      * bundler (1.11.2)
      * foreman (0.78.0)
      * foreman (0.74.0)
      9501ac70
  17. 01 Mar, 2016 1 commit
  18. 23 Feb, 2016 2 commits