search

drush-ops / drush

Drush is a command-line shell and scripting interface for Drupal, a veritable Swiss Army knife designed to make life easier for those who spend their working hours hacking away at the command prompt.
https://www.drush.org
2.33k stars 1.08k forks source link

Additional commands for CMI #228

Closed webflo closed 10 years ago

webflo commented 10 years ago

I uploaded our (@UEBERBIT) Drupal 8 project template yesterday. It contains a few drush commands to easy the developer workflow. @berdir and some other people from IRC liked the drush commands and suggested they should be in Drush core.

We should discuss how these commands should work and which options we need. Basically this is the equivalent to features-update/revert in D7.

Please look at drush/cmi.drush.inc

Some background information: CMI Workflow on Drupal Answers, D8 Project Template

weitzman commented 10 years ago

In general, I agree that this functionality is appropriate for Drush core. Thanks.

  1. Whats the permissions hack in config-export? Is that really necessary?
  2. Without the perm change, config-export becomes a special case of config-copy. Maybe we only offer config-copy and add a shell alias for config-export with hard coded arguments
  3. I have not used the -p option on git add. That looks pretty powerful and complex. Perhaps you can share how you use it.
  4. Commands need examples and need to support --simulate. Usually the easiest way to do that is to run mutative operations through drush_op().

Perhaps @msonnabaum and others could chime in on what they envision here.

webflo commented 10 years ago

Just a quick answer for 1 and 3. I try to work on examples and --simulate soon.

(1.) In my local env, the webserver writes the config files with 755. It is just to make sure that there are no unnecessary permission changes which pollute this git diff. Maybe thats a problem which my local configuration? All other files are 644 by default. I think it makes sense to maintain the same permissions for config files.

(3.) I use the -p option to stage/commit only some changes from my configuration. I like to split changes in multiple commits meaningful instead of one big "snapshot commit". It is also a good practice to review the changes.

fago commented 10 years ago

oh, I just opened a related PR that implements config-export - see #253 I've been using rsync to implement the command to speed things up though. Sry for the dupe, but I guess github cannot handle multiple PR/patches in one issue anyway?

@webflo I do not get how you use the export directory, where is the difference between staging and export in your workflow?

webflo commented 10 years ago

@fago I thought Drupal delete the fields vom staging after a successful import. But currently it does not. So i think i your are right. I do not need the export folder at all.

weitzman commented 10 years ago

I committed @fago version of config-export. I think the main interesting bit that isn't committed from drush/cmi.drush.inc is the git add -p part. I think it is pretty novel and will give people good direction of how CMI should interact with git. On the other hand, it is just one CLI command and folks can run it by hand if they want. So, not sure if config-export-git command belongs in Drush. It could alternatively be a commented out shell alias in example.drushrc.php

weitzman commented 10 years ago

Maybe we should add a --add option to config-export and that does the git add -p

weitzman commented 10 years ago

I did add the optional git operation BTW

webflo commented 10 years ago

Thanks, looks great!

weitzman commented 10 years ago

I just added the ability for config-export and config-import to use alternate $destination and $source respectively. I think that will be useful if folks use alternate directories to store config as proposed in that @UEBERBIT code. This obviates the need to copy files to $staging dir before importing, for example.