Command `provision-verify` should use the same functions and template to write the aliases that `provision-save` does.

Some findings..

1. Provision_Context()->write_alias() is NOT called on provision-verify, even tho the alias file does get saved again.
2. If you editing an alias manually, and run provision-verify, your edits exist, but are rearranged within the alias array, proving that somewhere, the alias gets saved again somewhere.
3. in Provision_Context_platform->init_platform(), adding an extra `$this->setProperty('alter', 'wtf');` does nothing.
4. In a real service that works, ie `Provision_Service_git->subscribe_platform()`, calling `$context->setProperty('alter', 'wtf');` does nothing.
5. Altering $data in Provision_Config_Drushrc_Alias()->__construct(), where you would think the $options are generated for the `'provision_drushrc_alias.tpl.php` file, does nothing.
6. Altering the `provision_drushrc_alias.tpl.php` file itself does nothing! I suppose this template is not used after the first provision_save?

This is giving me bad flashbacks to almost 3 years ago now, when I first started building devshop's tools.

Updating the title to reflect a possible solution.

DISCOVERY!

All of the modifications I made take effect when initially creating a platform via hostmaster. (or deleting the alias and re-verifying)

If we change the way provision-verify works to save the alias using the same objects and functions as the initial provision-save, I think we solve most of these problems.

Confirmed that you can use the following to alter the alias, before it is created with:

1. Provision_Context_platform->init_platform();
2. Provision_Config_Drushrc_Alias
3. provision_drushrc_alias.tpl.php

None of these work once the alias exists. This means adding any hook_alter() to these options will only work before the first save of the alias.

Let's fix this!

This patch kindof works.

However, if the "default" value of setProperty() is changed, the new default does not get written over the old one.

I guess that's why it's a "default"?

However this defeats my purpose, which is to change properties if needed on verify.

Baby steps.

Also, this just looks weird.

I really hate the d() command, it is incredibly ambiguous and amorphous.

Any tips on how we could do this correctly?

 function drush_provision_verify() {
   provision_backend_invoke(d()->name, 'provision-save');
   d()->command_invoke('verify');
 }
 

Ok, I altered setProperty() to have a $force parameter, so that functions can actually set parameters.

It seems to work!

Also added some comments to the function:

  /**
   * Check the $options property for a field, saving to the properties array.
   */
  function setProperty($field, $default = NULL, $array = FALSE, $force = FALSE) {
    // If the options already has the $field...
    if (isset($this->options[$field])) {
      // If the options property is null, or property is being forced, used default value.
      if ($this->options[$field] === 'null' || $force) {
        $this->$field = $default;
      }
      // If options property is supposed to be an array but has comma separated values, explode it.
      elseif ($array && !is_array($this->options[$field])) {
        $this->$field = explode(',', $this->options[$field]);
      }
      // Otherwise use options array value for the $field property.
      else {
        $this->$field = $this->options[$field];
      }
    }
    // If the options doesn't have the field, use default value.
    else {
      $this->$field = $default;
    }
  }

Here's what my git service class looks like. This sets the alias property ALTER no matter what!

class Provision_Service_git extends Provision_Service {
  public $service = 'git';

  static function subscribe_platform($context) {
    $context->setProperty('ALTER', 'I am a forced property', FALSE, TRUE);

    $context->setProperty('repo_url');
    $context->setProperty('deploy_from_git');
    $context->setProperty('git_ref');
  }
}

Ran through platform and site creation without problems.

I think the only catch here would be that we are calling "provision-save" twice when invoked from hostmaster. I believe this is because there is a pre hosting task hook that runs it before provision-verify. Now that provision-save is included in provision-verify, we can remove this.

I do now. :)

2358795-provision-save-on-verify

I think the only catch here would be that we are calling "provision-save" twice when invoked from hostmaster. I believe this is because there is a pre hosting task hook that runs it before provision-verify. Now that provision-save is included in provision-verify, we can remove this.

Ok, so we never did this...

provision-save is invoked from `drush_hosting_task`. This still needs to exist to make sure data is passed from hostmaster...

Not sure why I really need or want provision-save to be invoked on provision-verify like that. It breaks