Ruby versions

Development
21

… will also decrease our travis build time somewhat

22

@florianstaudacher well if we introduce 2.1 instead of 1.9, this is unlikely, isn’t it?

23

2.1 is faster than 1.9 and 2.0. Compare build times between 2.0 and 1.9 on Travis.

24

If they keep erroring we should just bite it and drop 2.0 once we move to 2.1 - imho.

25

Proposal: Drop previous Ruby from the Travis builds

Unfortunately Travis builds are way too often still ending up in error. Our builds, doing both 2.1 and 2.0 for all tests, take up to or more than 4 hours - and at that time Travis kills the switch.

I’m under the feeling we’re not only getting bad automatic testing by trying to build too much, but also abusing the free service from the Travis guys.

My proposal is to stop building for 2.0 in development, since there the recommended version is 2.1. The .travis.yml ruby versions should match the ruby version of .ruby-version - and only that.

Vote;

  • YES - agree to build only for current recommended ruby version (per branch built)
  • NO - keep as is, eg build for two ruby versions

Outcome: Closed proposal early with no result

Votes:

  • Yes: 1
  • Abstain: 2
  • No: 0
  • Block: 0

Note: This proposal was imported from Loomio. Vote details, some comments and metadata were not imported. Click here to view the proposal with all details on Loomio.

26

Ah! Should have looked around a bit - indeed it is 50 minutes per build.

So dropping rubies will not stop errors completely, though it might make them less frequent.

I guess the real solution would be to break the test suites into smaller parts?

27

The real solution is to make our testsuite faster. For the cucumber that means looking into converting some cukes to jasmine/rspec tests, looking into if we can speedup database_cleaner which runs after every scenario and looking into whether alternate capybara drivers like poltergeist would speed things up. For rspec this means looking into creating less objects in the database where possible (using doubles and FactoryGirl.build over FactoryGirl.create where possible). We also could verify if we actually need all gems we install on Travis for the tests to run.

28

Anyway, the proposal was stupid, since I misunderstood the problem. So closing it.

Thanks for clarifying.

29

On ruby 2.2 the RSpec suite runs in 5 minutes on my core i5-540M (which is still slow, if you ask me). The only problem is eventmachine, you have to upgrade it.

30

@jhass using factory girl objects (and stubbing those out) instead of fixtures would bring very tangible speedups to the test suite. Also, as a last resort, we can use parallel_tests: probably most of us have multicore machines.

31

Yeah sure, we also recently cut down our cucumber suite run by a lot, by eliminating all the slow finders, there’s a lot of room for optimization in the testsuite :wink: We had parallel_tests once, but I don’t remember the reason of why it got dumped. As for CI that would bring no benefit since Travis containers only get 1.5 CPUs. Anyway, any patches that make stuff faster are very welcome!

32

Proposal: Drop Ruby 2.0 support, adopt Ruby 2.2 support

  • Official security maintenance for Ruby 2.0 will end February 24 2016.
  • Rails 5 will support Ruby 2.2 only.
  • Ruby 2.1 and 2.2 have largely improved garbage collection over Ruby 2.0.
  • Ruby 2.1 added required keyword arguments which can’t be used as a useful tool towards more correct code when supporting Ruby 2.0

Outcome: No objections, accepted. The next major version will implement these changes.

Votes:

  • Yes: 10
  • Abstain: 2
  • No: 0
  • Block: 0

Note: This proposal was imported from Loomio. Vote details, some comments and metadata were not imported. Click here to view the proposal with all details on Loomio.