Broken travis from other repos

[himdel]

With some frequency, ui-classic travis is red because of changes made in other repos.

This issue exists to track those - please mention this issue in any PR which breaks ui-classic travis (or fixes such a break).

(Please do not use for travis failures not caused by other ManageIQ repos.)

(related to discussion in ManageIQ/manageiq#18173)

Spreadsheet: https://docs.google.com/spreadsheets/d/1V_o2vxaBsHlX70E0SOwoeArmXAZIfQQI8V_JBC8dGvE

[Fryguy]

If, possible, I would love to see the following timings:

• Time when ui-classic went red
• Time when it was discovered that ui-classic went red (helps us understand TZ complications where it goes red in the middle of your night, and then not discovering that until the morning)
• Time when it was determined that core caused the red
• Time when PRs are created to fix it
• Time when PRs are merged
• Time when ui-classic goes green

Obviously it may not be possible to get all of that, but the more information we have the better we can solve this together.

[himdel]

Red again...
https://travis-ci.org/ManageIQ/manageiq-ui-classic/builds/455654431

  1) ComplianceSummaryHelper when @explorer is set #textual_compliance_status
     Failure/Error: {:time => time_ago_in_words(date.in_time_zone(Time.zone)).titleize}
     NoMethodError:
       undefined method `in_time_zone' for nil:NilClass
     # ./app/helpers/compliance_summary_helper.rb:16:in `textual_compliance_status'
     # ./spec/helpers/compliance_summary_helper_spec.rb:22:in `block (3 levels) in <top (required)>'
  2) ComplianceSummaryHelper for classic screens when @explorer is not set #textual_compliance_status
     Failure/Error: {:time => time_ago_in_words(date.in_time_zone(Time.zone)).titleize}
     NoMethodError:
       undefined method `in_time_zone' for nil:NilClass
     # ./app/helpers/compliance_summary_helper.rb:16:in `textual_compliance_status'
     # ./spec/helpers/compliance_summary_helper_spec.rb:50:in `block (3 levels) in <top (required)>'

PR merged: 2018-11-15 16:53 UTC
travis went red: 2018-11-15 20:03 UTC
discovered: 2018-11-16 13:30 UTC (me, presumably sooner by others?; 12:23 UTC on Brno gitter)
core caused: about 30 minutes, ManageIQ/manageiq#17475
(Thanks @Hyperkid123 for finding the problem (can you add how much time you spent on it too please?))
EDIT: so, an hour

fix created: 2018-11-16 14:10 UTC (assuming #4933)
PR merged: 2018-11-16 19:06 UTC
travis went green: 2018-11-16 19:42 UTC (https://travis-ci.org/ManageIQ/manageiq-ui-classic/builds/456115082)

[Hyperkid123]

Thanks @Hyperkid123 for finding the problem (can you add how much time you spent on it too please?

It took me about 15-20 minutes. And about 30 minutes until i realized that the tests are busted (don't know if that counts). Thanks for the fix @himdel !

[skateman]

This could be nicely automated by just storing some information about PR merges and travis build results from all the related repos. If the PR's build was green and the master branch afterwards went red, there's probably an issue in the other repositories. This is way too interesting to solve during working hours, if no one wants it, I might play with this during the holidays in December.

[bdunne]

@skateman That does sound like a fun project 😄

[martinpovolny]

@bdunne, @Fryguy:

on the argument of long running UI tests: We fixed that.

[himdel]

Another red...

https://travis-ci.org/ManageIQ/manageiq-ui-classic/jobs/474623058

  1) PhysicalInfraTopologyService#build_topology topology contains the expected structure and content
     Failure/Error:
       expect(subject[:items]).to eq(
         "PhysicalInfraManager" + ems.id.to_s  => {
           :name         => ems.name,
           :kind         => "PhysicalInfraManager",
           :miq_id       => ems.id,
           :status       => nil,
           :display_kind => "Lenovo",
           :model        => ems.class.name,
           :key          => "PhysicalInfraManager" + ems.id.to_s
         },
       expected: {"PhysicalInfraManager96000000000077"=>{:name=>"LXCA", :kind=>"PhysicalInfraManager", :miq_id=>960000...PhysicalServer", :provider=>"LXCA", :model=>"PhysicalServer", :key=>"PhysicalServer96000000000004"}}
            got: {"PhysicalInfraManager96000000000077"=>{:name=>"LXCA", :kind=>"PhysicalInfraManager", :model=>"Manage..."PhysicalRack96000000000001", :status=>"Unknown", :display_kind=>"PhysicalRack", :provider=>"LXCA"}}

(hidden in the diff, but expected has :status => nil, while actual has :status => 'Valid').

Comes from ManageIQ/manageiq#18266.
Fixed by #5120

Merged: 2019-01-02 15:17Z
Went red: 2019-01-02 16:51Z
Discovered: 2019-01-03 10:53Z
Fix created: 2019-01-03 12:27Z
PR merged: 2019-01-03 12:49Z
Went green: 2019-01-03 13:03Z

[cben]

Thanks, now I know what broke providers-kubernetes tests, being subscribed to this issue saves a lot of time debugging 😉

[Fryguy]

I made a spreadsheet... link in the OP.

[himdel]

Another..

https://travis-ci.org/ManageIQ/manageiq-ui-classic/jobs/485263617

  1) TopologyService#entity_name entity is a tag returns with the parent and the child classification description
     Failure/Error: cond.exists?
     SystemStackError:
       stack level too deep
     # ./spec/manageiq/app/models/classification.rb:16:in `block in <class:Classification>'
     # ./spec/manageiq/app/models/classification.rb:533:in `save_tag'
...
     # ./spec/manageiq/app/models/classification.rb:533:in `save_tag'
     # ./spec/manageiq/spec/support/missing_factory_helper.rb:10:in `create'

Caused by ManageIQ/manageiq#18378

Fixed... ?

(added dates to spreadsheet)