| Project: | Git deploy |
| Version: | 7.x-1.x-dev |
| Component: | User interface |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
(Hard to come up with a concise summary of this bug in the title). ;)
The first time you view the available updates report when there's no cached available release data (e.g. you just saved the modules page and you visit the report before you click on one of the "check manually" links), cvs_deploy is in a sad state. When hook_system_info_alter() gets invoked, we don't have any cached data, and we therefore can't convert the version from HEAD into something else. Update status then fetches data, and compares the status, but it's going to think the version is not supported, since it doesn't know what version you're actually running and couldn't find any release information that matched what you've got (the release says the version is "7.x-1.x-dev", but it's looking for a version called "HEAD"). Lots of bogus results ensue. If you reload the page they go away. Yuck.
However, we can detect this edge case before we display it, and reload the page at that point, thanks to the miracle of hook_update_status_alter(). Patch coming soon, stay tuned.
Comments
#1
#2
I get stuck in a redirect loop.
Wouldn't the function be
cvs_deploy_update_status_alter(&$projects)?Also, is there a reliable way to trigger the edge case? It would make testing easier.
#3
I think the redirect was due to #881694: cache_update.cid has changed.
Changed $projects to &$projects and "Implement" to "Implements".
#4
Actually, I don't think we want a reference to $projects, since we're not altering anything in there. If it's read-only, it's more defensive programming to not take it as a reference...
Argh, core changed its mind *again* on implement vs. implements. /me throws up hands in disgust. ;)
Thanks for testing! I'll get this in soon, just in the middle of a few things.
-Derek
#5
Friendly bump, removed the &.
#6
Still works great, rerolled to get rid of fuzz.
#7
Yeah, finally got back to testing this. Works fine, so I committed to HEAD. Thanks for being persistent. ;)
#8
Tested this on D6, too. Works there, as well. Committed to DRUPAL-6--1.
#9
Except this is still broken in the Update manager UI, e.g. at admin/modules/update and admin/appearance/update. The D6 backport is immune to this problem, since the Update manager is new in D7. But, we should see if it's possible to fix the Update manager in D7, too.
#10
This depends on #929756: Update manager UI uses stale project data getting into core. Then it works great.
#11
Oh, and this work-around also doesn't work if you've viewing any of this stuff inside the overlay. :(
/me stabs the overlay in the eye with a flaming knife.
Now we have to figure out how to figure out what page you're on when you're inside the overlay. Argh.
#12
cvs_deploy is dead. Long live git_deploy.
However, it's possible this same bug exists over here, and it's worth investigating that before setting this to won't fix. It's mitigated by the fact that -dev releases from 'master' are a dying breed (and no new such releases will ever exist), so maybe we should just "won't fix" this issue on principle. But, there are still a lot of -dev releases from master, and I doubt git_deploy handles this any better/differently than cvs_deploy did. I'll let halstead have the honors of killing this issue if he's so inclined. Or, I can try to remember more clearly the details of what's going on here and help try to harden git_deploy against it.
#13
This is either fixed or maybe won't fix. Releases from master are gone. Git_deploy 1.x did its best to refresh the cache. Git_deploy 2 will always return something the first time unless no release has ever been tagged. So this will occur so rarely it's no longer an issue IMO.
#14
Automatically closed -- issue fixed for 2 weeks with no activity.