You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 5, 2025. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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
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.
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 thedrush.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.
The text was updated successfully, but these errors were encountered: