Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.It might be related to an upgrade issue but at the moment out verify task only reads the git url and current branch when it 'knows' the site is managed in git.
Can we either add an 'import git settings' task, or let is check some other way?
We could just always check for the existence of .git meta info in the filesystem... would that be serious overhead?
The most relevant code in hosting_git.drush.inc ... where deploy_from_git gets set.
/**
* Implements hook_hosting_TASK_OBJECT_context_options().
*/
function hosting_git_hosting_platform_context_options(&$task) {
// Set some defaults.
$task->context_options['deploy_from_git'] = FALSE;
$task->context_options['git_ref'] = '';
// If we're actually provisioning from Git, populate real data.
if (!empty($task->ref->git['repo_url'])) {
$task->context_options['repo_url'] = $task->ref->git['repo_url'];
$task->context_options['deploy_from_git'] = TRUE;
$task->context_options['git_ref'] = $task->ref->git['git_ref'];
}
$task->context_options['deploy_from_git'] = TRUE;
}
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | pickup_git_setting_from-2544906-3.patch | 2.77 KB | helmo |
| #2 | pickup_git_setting_from-2544906-2.patch | 1.75 KB | helmo |
Comments
Comment #1
ergonlogicThis seems reasonable. I don't think looking for
.git/in a site/platform root on verify tasks would add any significant overhead. If one is found, we should probably do some basic sanity checks to confirm that it is indeed a working git repo, that we can read from at least one remote, etc.Comment #2
helmo CreditAttribution: helmo at Initfour websolutions commentedHere's a bit of work in progress code.
I had it working for a bit with two verify tasks run after each other on a site. But it needs more though.
Comment #3
helmo CreditAttribution: helmo at Initfour websolutions commentedThis still itched .... and while working on #2871078: Saving site removes GIT credentials I started digging again.... this patch seems to work ... needs testing though.
Comment #5
helmo CreditAttribution: helmo at Initfour websolutions commentedCommitted, It worked as expected on multiple sites.
Comment #7
Jon PughThis is way too loose.
My site nodes are getting the git information imported from the platform, and then the platform git repo cloned into the sites folder!
Still investigating...
Comment #8
Jon PughI think I tracked it down to this:
If we 'cd' to $repo_path and run that, we will get a result if the platform is a git repository.
is there a way to force `git config` to use only an exact folder, and not a parent? Or should I just check for .git folder?
Comment #9
Jon PughFor reference, this other issue was caused by this patch: #2893588: Removing a site or platform could remove all of /var/aegir
Comment #11
helmo CreditAttribution: helmo at Initfour websolutions commentedYour changes in 2544906-import-meta look OK, but I haven't been able to reproduce the problem yet.
I checked a site (that has no git) on a platform that is in git .... and a verify task there did not pick up git settings into the site.
But after merging 2544906-import-meta I didn't notice problems.
Comment #12
helmo CreditAttribution: helmo at Initfour websolutions commentedWhat about calling provision_git_is_repo() from _provision_git_update_git_meta_data()? with the force_repo_path_as_toplevel option ...
Comment #13
Jon PughOne reason is that it's already being called before running the meta data hook:
provision_git_is_repo() does a lot more than just check a directory, it checks drush options, runs git status, drush log...
This was just for a final sanity check before importing that metadata.
Comment #14
Jon PughI'm inferring from helmo in #11 and #12 that this is RTBC
Comment #16
Jon Pugh