When using alternative data centers, the URLs displayed for links to the job details page might not be correct. We should check.

i set the status (change_status) of my tests in saucelabs. With the new datacenter (eu-central-1) the url of the saucelabs rest api is changed to 'https://eu-central-1.saucelabs.com/rest' and this gem isn't working for me. How can I set the url manually?

sauce_whisk

ENV['SAUCE_USERNAME'] ||= 'test_user'
ENV['SAUCE_ACCESS_KEY'] ||= 'test_key'

sauce-java

private static final String SAUCE_USER_NAME = "SAUCE_USER_NAME";
private static final String SAUCE_API_KEY = "SAUCE_API_KEY";

I think Sauce should have a standard naming convention for the ENV vars instead of different values for each project.

We have set up our specs based on this example, yet we run into this error as soon as we have more than a single spec:

Failure/Error: SauceWhisk::Jobs.change_status(@driver.browser.session_id, !example.exception)
NoMethodError: undefined method `browser' for nil:NilClass

our sauce_spec_helper.rb has the following (ie the same stuff as the example with the addition of a flag we use specifically for Travis):

config.after(:each, skip: do_not_run_on_sauce?) do |example|
  SauceWhisk::Jobs.change_status(@driver.browser.session_id, !example.exception)
  @driver.quit
end

Any idea on what could be causing this?

We should be able to call .delete on a job object.

Gemnasium shows sauce_whisk has a security alert due to rest client however this has been fixed already. I suspect the gemnasium hook is not setup properly since it's been 15 days since this change.

Sauce whisk is locking to rest-client ~> 1.7.1 which has security issues:

rest-client/rest-client#369

Are the tests passing for you on master? I exported a sauce user and key yet they're still failing.

$ rspec
PSYCH: 2.0.5
........................F....................F........F..FF..F...............................F...F..FF.F.

I contributed the code for the Asset deletion, however at the time I had named the method asset_delete as opposed delete or rest_delete due to a collision I was seeing. It looks like an alias was created, but unfortunately it looks like it deletes the entire job and not the assets.

SauceWhisk::Assets.rest_delete "459887345

If I look at the url that's invoked by the above, it's trying to delete the asset:

https://saucelabs.com/rest/v1/dfranko/jobs/459887345

I'd be happy to fix this, I just don't know what the correct way of doing so would be.

https://travis-ci.org/DylanLacey/sauce_whisk/builds

Is sauce_whisk still maintained? The CI hasn't run in 8 months. In addition, the test command it used is broken.

bundle exec rake

That doesn't even run the tests.

How do I resolve this error?

Unable to activate sauce_whisk-0.0.21, because json-2.0.3 conflicts with json (~> 1.8.1)

$ rake install
sauce_whisk 0.0.12 built to pkg/sauce_whisk-0.0.12.gem.
sauce_whisk 0.0.12 built to pkg/sauce_whisk-0.0.12.gem.
sauce_whisk (0.0.12) installed.
sauce_whisk (0.0.12) installed.

The problem is require "bundler/gem_tasks" must not be in the Rakefile or the install task is defined and executed twice.

The key for visibility is public not visibility so I'm unable to change this value with SauceWhisk.

Nothing happens when rake test is executed. Have these tests ever run via Rake?

$ bundle install
$ rake test

Does this support the storage API?
https://github.com/bootstraponline/sauce_storage

(ENV is setup correct, confirmed by SauceWhisk.password and by using them aganst the rest api)

SauceWhisk::Accounts.fetch

<SauceWhisk::Account:0x007f88cd09ca60

@access_key=nil,
@mac_concurrency=5,
@minutes=nil,
@total_concurrency=5,
@username=nil>

When calling SauceWhisk::Jobs.fetch job_id an error occurs in initialize of lib/sauce_whisk/jobs.rb:100. I dug into it and nil was being passed in as the parameters to initialize. This was initiated from the self.fetch on line 46 of same file. When I stepped through it I found that the get job_id was failing with RestClient::ResourceNotFound Exception: 404 Resource Not Found. I was able to discern the job_id I was passing into fetch was incorrect, but there could be better error handling around RestClient exceptions.

There seems to be a bug with the sauce_whisk gem against Ruby 3.2.2. When I tried it out it crashes like so...
/usr/local/rvm/gems/ruby-3.2.2/gems/sauce_whisk-0.3.2/lib/sauce_whisk.rb:144:in block in load_options_from_yaml': undefined method exists?' for File:Class (NoMethodError)

if File.exists? path

This article suggests it's a problem with backwards compatibility in Ruby 3.2
https://stackoverflow.com/questions/14351272/undefined-method-exists-for-fileclass-nomethoderror

Not sure if this was by intent... but there are no variables for device-orientation when you are running against iOS clients

Attempting to create a new 'empty' job, per the documentation,

job = SauceWhisk::Job.new job_id

results in the following error:

 ArgumentError:
  invalid range "m-d" in string transliteration
  # /usr/local/rvm/gems/ruby-1.9.3-p194/gems/sauce_whisk-0.0.10/lib/sauce_whisk/jobs.rb:80:in `delete'
  # /usr/local/rvm/gems/ruby-1.9.3-p194/gems/sauce_whisk-0.0.10/lib/sauce_whisk/jobs.rb:80:in `initialize'

I'm not exactly sure what the expectation is for the response time for the service status, but this seems too long to me. Perhaps there's a better method for me to use to check if the service is up?

2.0.0-p195 :019 > 10.times do
2.0.0-p195 :020 >     start = Time.now
2.0.0-p195 :021?>   puts SauceWhisk::Sauce.service_status
2.0.0-p195 :022?>   puts "Duration : #{Time.now - start}"
2.0.0-p195 :023?>   sleep 10
2.0.0-p195 :024?>   end

{:wait_time=>3.7078734363502575, :service_operational=>true, :status_message=>"Basic service status checks passed."}
Duration : 5.853709
{:wait_time=>3.144050104384134, :service_operational=>true, :status_message=>"Basic service status checks passed."}
Duration : 11.758652
{:wait_time=>3.6678224687933425, :service_operational=>true, :status_message=>"Basic service status checks passed."}
Duration : 11.537582
{:wait_time=>2.587360594795539, :service_operational=>true, :status_message=>"Basic service status checks passed."}
Duration : 27.473724
{:wait_time=>5.043506921555702, :service_operational=>true, :status_message=>"Basic service status checks passed."}
Duration : 15.525515
{:wait_time=>5.559947299077733, :service_operational=>true, :status_message=>"Basic service status checks passed."}
Duration : 17.325829
{:wait_time=>6.0932642487046635, :service_operational=>true, :status_message=>"Basic service status checks passed."}
Duration : 6.790501
{:wait_time=>6.3870112657388995, :service_operational=>true, :status_message=>"Basic service status checks passed."}
Duration : 8.320454
{:wait_time=>6.376744186046512, :service_operational=>true, :status_message=>"Basic service status checks passed."}
Duration : 20.616669
{:wait_time=>6.577963917525773, :service_operational=>true, :status_message=>"Basic service status checks passed."}
Duration : 3.925932

Let the REST API use ondemand.yml to configure its auth values.

This will prevent the sauce:spec task from freaking out when users are using ondemand.

I didn't see this documented.

https://github.com/saucelabs/sauce_whisk/releases shows 0.0.17 as the latest release although rubygems shows 0.0.18. Is there a reason the latest release wasn't tagged on github?

SauceWhisk::Jobs.fetch job_id

is returning this
RestClient::BadRequest: 400 Bad Request
from /Users/malugus/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/rest-client-1.6.7/lib/restclient/abstract_response.rb:48:in `return!'

This works after a bit, if Sauce API is not reliable you should add an implicit retry loop.