I'm listing this as a feature request, but it could just as easily be considered a bug. If a site is on a platform on a remote server, a 'git pull' won't have any effect on the site being served, until it is verified, and thus sync'd out to the remote.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ergonlogic’s picture

This will probably equally apply when the platform is managed under git.

formatC'vt’s picture

Assigned: Unassigned » formatC'vt

i'm working on it

formatC'vt’s picture

Status: Active » Needs review
FileSize
3.96 KB

Added an option with trigger flag (checkbox) to git settings

helmo’s picture

Not sure what is going wrong but we already have code for that ... http://cgit.drupalcode.org/hosting_git/tree/pull/hosting_git_pull.module...

formatC'vt’s picture

ergonlogic’s picture

It looks like these hooks are in the .module, which'd explain why they aren't being invoked. I'm pretty sure they'd have to live in a .drush.inc for that.

formatC'vt’s picture

I think you are right. But what is the best way to implement this issue hook_post_hosting_TASK_TYPE_task() or drush_hook_post_COMMAND()?

ergonlogic’s picture

drush_hosting_git_pull_post_provision_git_pull(), as written, should work just fine, assuming it's moved to a file called hosting_git_pull.drush.inc.

In this case, the Drush hook is preferable, since the verify is an integral part of the git pull operation. That is, we want it to happen, even if there is no front-end triggering it. In the hosting post task hook, we'd have to queue up the verify task, which is a counter-pattern in general.

formatC'vt’s picture

Status: Needs review » Needs work

ok, i will try this way

ergonlogic’s picture

Category: Feature request » Bug report

Since we already have code intended to do this, the fact that it isn't working is clearly a bug.

Also, I don't really think we need a front-end flag for this. Without a verify, the updated code won't propagate. I don't see a use-case for not running the verify, especially since it will attempt to fix permissions, etc.

helmo’s picture

I just tried this again in production and for me it "just works". The code was pulled on the master server and rsync'd to the slave server.

formatC'vt’s picture

rsync'd without verify task?

ergonlogic’s picture

I'm not seeing the behaviour in #11. There's no verify/rsync happening in my tests.

formatC'vt’s picture

Maybe he uses checkout instead pull. Anyway i'm working on it, but just create files 'MODULE_NAME.drush.inc' and add hooks drush_hosting_git_pull_post_provision_git_pull() and drush_hosting_git_checkout_post_provision_git_checkout() not working. I will try find enough time on this week to find what is wrong and why these hooks not invoked.

formatC'vt’s picture

Status: Needs work » Needs review
FileSize
3.31 KB

done

gboudrias’s picture

Issue tags: +Aegir 3.1
cweagans’s picture

I haven't tested this on a real Aegir install, but it looks good to me. It's just moving code around as far as I can tell. I won't RTBC, but if somebody else wants to test it and make sure it works as expected, feel free to consider the code reviewed :)

gboudrias’s picture

Issue tags: -Aegir 3.1
helmo’s picture

Status: Needs review » Needs work

Sorry but the patch from #15 is not good for me.

On a checkout task I without the patch I get a verify, with the patch applied no verify happens.

I think #3had a better hook for a verify after pull.

formatC'vt’s picture

Without patch the verify is separate task in UI, with patch the verify is an integral part of the git checkout operation (not a separate task in UI). Check task log for Calling hook drush_provision_git_post_provision_verify please

  • helmo committed 5239896 on 7.x-3.x authored by formatC'vt
    Issue #2541758 by formatC'vt: Trigger verify after "git pull" task when...
helmo’s picture

Status: Needs work » Fixed

Seems to work now, committed. I also moved more code to the pull and checkout sub modules.

It might have been Drush not picking up the new command files until the hostmaster site was re-verified.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.