Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drush alias #29

Open
Decipher opened this issue Jul 30, 2015 · 4 comments
Open

Drush alias #29

Decipher opened this issue Jul 30, 2015 · 4 comments
Milestone

Comments

@Decipher
Copy link
Contributor

It'd be really nice if a Drush alias was created and 'drush use'd so that interactions with the Drupal site could be done without the need of navigating the filesystem.

Decipher added a commit to Decipher/drupal_ti that referenced this issue Jul 30, 2015
@LionsAd LionsAd added this to the 1.5.0 milestone Jul 30, 2015
LionsAd added a commit that referenced this issue Jul 30, 2015
#29: Add `drush site-set` after site installation.
@LionsAd
Copy link
Owner

LionsAd commented Jul 30, 2015

I still think this makes sense regardless of this, especially using the behat extension with its alias feature.

@Decipher
Copy link
Contributor Author

I agree it makes sense, although I'm not familiar with the alias feature of the behat extension, will look into it.

Ideally I was hoping to take a super simple approach to the Alias, by piping the output of 'drush sa @self' from within the site directory out to an alias file, which would get you halfway there, but the assigned alias would be 'self', which is relatively un-descriptive.

The other reason I didn't go down that track is just my lack of understanding on how best to fork and test a composer based package with Travis. I did try forking, and updating the namespace for the drupal_ti, but it appears it's not as easy as that, so any advice would be appreciated.

@LionsAd
Copy link
Owner

LionsAd commented Jul 31, 2015

Forking is really simple:

Just fork and then instead of:

composer require lionsad/drupal_ti

you do something like:

- git clone yourrepo/drupal_ti
- mkdir -p "$HOME/.composer/vendor/bin"
- ln -sf $(pwd)/drupal_ti/drupal-ti "$HOME/.composer/vendor/bin"

drupal_ti can work from everwhere.

That is the trick I use to have drupal_ti test 'itself'.

@Decipher
Copy link
Contributor Author

Thanks, that's clearly obvious. I'll give it a spin shortly.

@LionsAd LionsAd modified the milestones: 1.5.0, 1.6.0 Dec 12, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants