New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pickup Tower Project's repo-sync status #14687
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
besides rubocop alignment 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is going to be confusing. Brace yourselves.
When we branched fine
we changed the spec that insures migrations will always be run in order. This makes backporting migrations to fine
... difficult.
Since fine was branched more migrations have been added to master, specifically these:
20170324124452_add_vendor_property_to_physical_server.rb
20170328110106_fix_expression_in_tenant_quota_report.rb
20170404213245_add_loc_led_state_to_physical_servers.rb
These migrations were not backported to fine
.
The last migration in the fine
branch is 20170320195659_remove_oid_integer_args_from_miq_queue.rb
This means that for us to backport this safely, your migration needs to be numbered between 20170320195659
and 20170324124452
- preferably an earlier number, in case we need to do this again. I'll go ahead and suggest 20170320195660
Checked commits jameswnl/manageiq@46ae44b~...dd66fdd with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @jameswnl
@miq-bot add_label bug |
Pickup Tower Project's repo-sync status (cherry picked from commit 84006ef)
Fine backport details:
|
To allow user to know if Tower's latest attempt to sync a repo's playbooks is successful or not.
Part of the pivotal tracker story
Note: the other property we can use (instead of
last_update_failed
) is thestatus
([successful|failed|missing|...]
). Obviously, we can have both of them (plus some other fields) captured. They all give us different aspects of the repo state. But I think we probably want to be as frugal as possible. Andstatus
needs string comparison, vs thelast_update_failed
boolean
check, I pickboolean
.But 1 point to consider
status
is that In Tower, there's amanual
type repo, there wouldn't be a sync and solast_update_failed
won't be meaningful. Theproject.status
would show if there's problem with it.However, we only support
Git
type now. so I need someone to push one way or the other. ( @Fryguy @blomquisg )@miq-bot add_labels enhancement, providers/ansible_tower, fine/yes
==== Updates ====
Switched to pickup
status
instead oflast_update_failed
==== Related bug ====
https://bugzilla.redhat.com/show_bug.cgi?id=1439357