Travis CI Client (CLI and Ruby library) introduced v1.8.6 version: https://github.com/travis-ci/travis.rb/releases Reproducible: Always
Created attachment 463928 [details] dev-ruby/travis-1.8.6.ebuild Update proposal
Unfortunately there are many failing tests with this version and I have not been able yet to pinpoint why. Did you check your proposed ebuild with FEATURES=test ?
This might be a good time to add a slotted version of dev-ruby/typhoeus, for 0.6.*.
I`m able to run tests successfully as normal user: $ git clone https://github.com/travis-ci/travis.rb.git $ cd travis.rb $ /usr/bin/ruby21 -S rspec-2 spec At the same time portage tests fail for both versions (in-tree dev-ruby/travis-1.8.2-r1 and proposed dev-ruby/travis-1.8.6): # FEATURES="test" emerge -v =dev-ruby/travis-1.8.6 emerge output: http://pastebin.com/raw/kRrhp0Dx Also tried to disable sandbox restriction for tests, but the same number of tests fail (277 examples, 29 failures): # FEATURES="test -network-sandbox -sandbox -userpriv -usersandbox" emerge -v =dev-ruby/travis-1.8.6 Installation without FEATURES="test" does not emit errors for both in-tree dev-ruby/travis-1.8.2-r1 and proposed dev-ruby/travis-1.8.6. Any notes on how to debug portage tests in more details?
(In reply to Lik from comment #4) > I`m able to run tests successfully as normal user: > > $ git clone https://github.com/travis-ci/travis.rb.git > $ cd travis.rb > $ /usr/bin/ruby21 -S rspec-2 spec I see one failure here (on the 1.8.6 tag). > At the same time portage tests fail for both versions (in-tree > dev-ruby/travis-1.8.2-r1 and proposed dev-ruby/travis-1.8.6): > > # FEATURES="test" emerge -v =dev-ruby/travis-1.8.6 Even more fun: this fails for me even when running the spec manually in /var/tmp/portage/dev-ruby/travis. And all of the differences between the unpacked gem and the git repo don't seem to make a difference. > Any notes on how to debug portage tests in more details? Two common gotchas here are tty access (but I think I excluded that by manually running in /var/tmp/portage), and weird effects caused by the hard link mechanism that we use to create the copies for each ruby version. So maybe that is causing this.
Comment on attachment 463928 [details] dev-ruby/travis-1.8.6.ebuild # Copyright 1999-2017 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Id$ EAPI=5 USE_RUBY="ruby21" RUBY_FAKEGEM_RECIPE_DOC="rdoc" RUBY_FAKEGEM_RECIPE_TEST="rspec" RUBY_FAKEGEM_GEMSPEC="${PN}.gemspec" RUBY_FAKEGEM_EXTRAINSTALL="assets" inherit bash-completion-r1 ruby-fakegem DESCRIPTION="Travis CI Client (CLI and Ruby library)" HOMEPAGE="https://github.com/travis-ci/travis.rb" LICENSE="MIT" SLOT="0" KEYWORDS="~amd64" ruby_add_bdepend " test? ( >dev-ruby/rspec-2.12 >dev-ruby/rack-test-0.6 >dev-ruby/sinatra-1.3 ) " ruby_add_rdepend " >dev-ruby/faraday-0.9 >=dev-ruby/faraday_middleware-0.9.1 >dev-ruby/highline-1.6 dev-ruby/backports >dev-ruby/net-http-persistent-2.9 >dev-ruby/gh-0.13 >dev-ruby/launchy-2.1 =dev-ruby/typhoeus-0.6* >dev-ruby/json-1.8 >dev-ruby/pusher-client-0.4 " all_ruby_install() { all_fakegem_install newbashcomp "assets/travis.sh" "travis" }
Have some progress with tests. Tests can be completed successfully if working directory meets the following requirements: 1. Working directory is a git repo with configured remotes. 2. Working directory has .travis.yml file (even empty file works). Apparently tests were written for travis github repo what implies working directory to be a git repo. There are several places in code where working 'git' binary is required in PATH (maybe add dev-vcs/git to dependencies?), e.g.: $ grep -n -A 4 'def detect_slug' lib/travis/cli/repo_command.rb 64: def detect_slug 65- git_head = `git name-rev --name-only HEAD 2>#{IO::NULL}`.chomp 66- git_remote = `git config --get branch.#{git_head}.remote 2>#{IO::NULL}`.chomp 67- git_remote = 'origin' if git_remote.empty? 68- git_info = `git ls-remote --get-url #{git_remote} 2>#{IO::NULL}`.chomp $ grep -n 'git rev-parse' lib/travis/cli/setup/service.rb 56: @branch ||= `git rev-parse --symbolic-full-name --abbrev-ref HEAD`.chomp Manual steps to reproduce workaround for tests: # TEST_VERBOSE=true FEATURES="test" emerge -v =dev-ruby/travis-1.8.6 # cd /var/tmp/portage/dev-ruby/travis-1.8.6/work/ruby21/travis-1.8.6 # /usr/bin/ruby21 -S rspec-2 spec 277 examples, 29 failures # git init # git remote add origin https://github.com/travis-ci/travis.rb # /usr/bin/ruby21 -S rspec-2 spec 277 examples, 1 failure Failures: 1) Travis::CLI::Encrypt travis encrypt FOO bar -a Failure/Error: run_cli("encrypt", "FOO", "bar", "-a").should be_success expected success? to return true, got false # ./spec/cli/encrypt_spec.rb:46:in `block (2 levels) in <top (required)>' # wget https://github.com/travis-ci/travis.rb/raw/master/.travis.yml # /usr/bin/ruby21 -S rspec-2 spec 277 examples, 0 failures # ebuild travis-1.8.6.ebuild test 277 examples, 0 failures
Proposed ebuild edited a bit to include all requirements from travis.gemspec, removed deprecated ruby20 USE.
Created attachment 465508 [details] dev-ruby/travis-1.8.6 with tests Final version of ebuild with quick'n'dirty workaround for FEATURES="test". Include all ruby dependencies from travis.gemspec, add dev-vcs/git to DEPEND/RDEPEND.
Any comments or objections to proposed ebuild "dev-ruby/travis-1.8.6 with tests"? Thanks in advance.
(In reply to Christoph Junghans from comment #3) > This might be a good time to add a slotted version of dev-ruby/typhoeus, for > 0.6.*. I have not moved typhoeus 1.1.x to the "1" slot.
(In reply to Lik from comment #10) > Any comments or objections to proposed ebuild "dev-ruby/travis-1.8.6 with > tests"? Thanks in advance. I have just added travis 1.8.6 to the tree based on your approach to fixing the tests. Comments on your ebuild: There is no need for the rspec test dependency, this is handled by the eclass recipe It is best to always try to include new RUBY_TARGETS in USE_RUBY. In this case ruby22 is possible, and it would have uncovered a problem with each_ruby_test. It is better to make preparations in the prepare() phase, so I have moved your changes there (guarded by "if use test"). I have also moved them to all_ruby_* instead of each_ruby_*. Due to the hard-linking setup for the ruby-versions making the changes in each_ruby_test() does not do what you would logically think it does, and the changes only end up in the first ruby target. By making the changes in all_ruby_prepare() they are set up correctly for all ruby targets. Thanks for digging in and uncovering how we can avoid the test failures.
Thanks for valuable comments. Still want to reopen this bug. 1. DESCRIPTION section. Remove trailing whitespaces. 2. RUBY_FAKEGEM_EXTRAINSTALL section. Without 'assets' first run of travis cli fails to install .travis/travis.sh bash completion file: $ travis Shell completion not installed. Would you like to install it now? |y| y No such file or directory @ rb_sysopen - /usr/lib64/ruby/gems/2.2.0/gems/travis-1.8.6/assets/travis.sh for a full error report, run travis report Similar errors can be triggered by other functions too: # grep assets . -nR ./lib/travis/client/session.rb:7:require 'travis/tools/assets' ./lib/travis/cli/command.rb:4:require 'travis/tools/assets' ./lib/travis/tools/notification.rb:3:require "travis/tools/assets" ./lib/travis/tools/assets.rb:4: BASE = File.expand_path('../../../../assets', __FILE__) ./lib/travis/tools/completion.rb:1:require 'travis/tools/assets' 3. all_ruby_prepare stage. Removal of spec/cli/login_spec.rb. For the sake of avoiding "stty: 'standard input': Inappropriate ioctl for device" messages only, because tests actually complete with success. 4. RUBY_TARGETS. Agree with you, but several ruby targets introduce new bug due to poor design of RubyGems wrapper (compared to python-exec wrapper). When there is only one RUBY_TARGETS defined, RubyGems wrapper (generated by ruby-fakegem.eclass) set shebang to exact version of ruby interpreter (e.g. #!/usr/bin/ruby22). When there are two or more RUBY_TARGETS, RubyGems wrapper set shebang to '#!/usr/bin/env ruby' what is ambiguous. Here is the failure scenario: $ eselect ruby list Available Ruby profiles: [1] ruby21 (with Rubygems) [2] ruby22 (with Rubygems) [3] ruby23 (with Rubygems) * $ travis /usr/bin/travis:9:in `load': cannot load such file -- /usr/lib64/ruby/gems/2.3.0/gems/travis-1.8.6/bin/travis (LoadError) from /usr/bin/travis:9:in `<main>' Sure, this bug is not package-specific rather core, and there is a room for improvements. Yet today the work of a particular package in this bug will be more stable and predictable with an indication of the particular recommended version of the ruby in RUBY_TARGETS.
(In reply to Lik from comment #13) > > 1. DESCRIPTION section. > Remove trailing whitespaces. Fixed. > 2. RUBY_FAKEGEM_EXTRAINSTALL section. > Without 'assets' first run of travis cli fails to install .travis/travis.sh > bash completion file: Added with travis-1.8.6-r1 > 3. all_ruby_prepare stage. Removal of spec/cli/login_spec.rb. > For the sake of avoiding "stty: 'standard input': Inappropriate ioctl for > device" messages only, because tests actually complete with success. I don't see that message, but the test fails for me instead. > 4. RUBY_TARGETS. > Agree with you, but several ruby targets introduce new bug due to poor > design of RubyGems wrapper (compared to python-exec wrapper). > Sure, this bug is not package-specific rather core, and there is a room for > improvements. Yet today the work of a particular package in this bug will be > more stable and predictable with an indication of the particular recommended > version of the ruby in RUBY_TARGETS. There are some bugs open for handling of RUBY_TARGETS/USE_RUBY mismatches in various ways. That situation certainly can be improved, but currently nobody is working on that.
