Skip to content
This repository was archived by the owner on Mar 5, 2025. It is now read-only.

drush problem with deploy:acsf:init #356

Closed
dpagini opened this issue Sep 2, 2016 · 3 comments
Closed

drush problem with deploy:acsf:init #356

dpagini opened this issue Sep 2, 2016 · 3 comments
Assignees
Labels
Bug Something isn't working

Comments

@dpagini
Copy link
Contributor

dpagini commented Sep 2, 2016

Wanted to submit this issue to see if anyone else is having a similar problem, or if I'm missing something easy here. I just recently upgraded our repo to the 8.3 release of acquia/blt. My deploy step is failing now, however.
The failure is on the acsf-init drush command. The phing target deploy:acsf:init is calling a drush script in the acsf module, and passing in the "-r" (or --root=) parameter with the deploy folder as the value. The problem is, the drush command is picking up the drush.wrapper file in the repo root, which overrides the drupal root parameter passed in by the phing target in favor of the repo root, not the deploy root. This is causing some havoc, as we are trying to perform the drush command on the deploy root, but the code being run is in the repo root.

I have fixed this locally by using a deploy_exclude file to ensure the drush.wrapper file is copied over to my deploy folder. Since I don't want this file on my Acquia repo, I then need to modify the .gitignore provided by blt to ignore that file. This seems to work well, but I'm not sure it's the best approach. If you all think this works, I can submit a PR for this approach.

Alternatively, I think it would make sense if drush.wrapper changed a little to see if the drush command already has the root set, and if so, use that instead of the "{$DOCROOT}" variable it's using now (or dont override the root if it's already set). This shell scripting is a bit beyond my area of comfort however, so I might defer to someone else more comfortable coding that piece...?

Thoughts?

Happy to help or answer questions if anything above was unclear.

@grasmash grasmash added the Bug Something isn't working label Sep 2, 2016
@grasmash
Copy link
Contributor

grasmash commented Sep 2, 2016

Are you sure that it's picking up on drush.wrapper? This is the task:
<exec dir="${deploy.dir}/docroot" command="${drush.bin} --include=${deploy.dir}/docroot/modules/contrib/acsf/acsf_init acsf-init -r ${deploy.dir}/docroot -y" logoutput="true" checkreturn="true" level="info" passthru="true"/>

This specifically executes the command from deploy/docroot which should not have access to drush.wrapper.

grasmash added a commit to grasmash/bolt that referenced this issue Sep 2, 2016
@grasmash grasmash self-assigned this Sep 2, 2016
@grasmash
Copy link
Contributor

grasmash commented Sep 2, 2016

Looks like you were absolutely right, but it beats me how drush is finding that drush.wrapper. In any case, I've worked around the issue by changing the order in which the two contradicting -r parameters are passed, allowing the one defined by deploy:acsf:init to take precedence.

@dpagini
Copy link
Contributor Author

dpagini commented Sep 2, 2016

great, thanks @grasmash! I thought there would be a better way to fix this.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants