stop behat on 500 errors with mink

I had some issues diagnosing 500 errors that were happening with Mink. The main issue being that a page would 500, but then the test would proceed and fail a later step. Unfortunately the HTML/screenshot that was captured does not capture the error, but instead captures the assertion which doesn’t help debug.

It’s possible to react after a step and check if the last Mink request was a 500 or not. This way, we fail on the 500, and not on the subsequent assertions.

 

PHP commandline OAuth authorization for JIRA

I needed to get a user’s OAuth credentials from the commandline, for some commandline tools to work (Drush).

You will need OAuth installed from PECL for this, and have an OAuth link set up in JIRA (or whatever OAuth provider you are using).

 

launch a jenkins slave via drush

If you already have Drush aliases set up for your live machines, deploy those aliases to your CI server, and use them to launch your nodes (instead of copying the SSH info).

Create a new “Dumb slave” but instead of “SSH slave”, select “Launch slave via execution”

This is the command to use:

Jenkins will run the command which sets up the remoting capabiliity.

A pretty good iframe resizer

 

drush uli gets “access denied” using vagrant

I noticed randomly “drush uli” would just result in “access denied” when Drupal was inside of a Vagrant machine.

The funny this was, if I waited a little bit, and tried the user login link again, it worked fine.

The problem is the Vagrant machine’s clock may be only a few seconds ahead of your local machine.

So the token that uli generates isn’t valid until then.

Solution: install “ntp” on both your host and inside the Vagrant machine.

dynamic drush alias files

Alias files are useful. If you have many sites on a remote server, instead of manually adding them to your alias file every time, write some code to automatically generate them.

Now whenever a site is configured on your target server, you will automatically have the alias!

consider versioning your .drush directory

Our team uses Drush frequently during the entire development workflow for doing things like grabbing database dumps of sites and running commands – drush make, registry rebuild, custom company-specific ones, etc. – and in the past everyone would have to manually download or copy them to their .drush.

Now, we version the .drush directory, so when a new developer onboards, they can just checkout the .drush directory from version control.

This is incredibly useful for

You can build a very powerful devops toolkit across all team members since everyone will have the same Drush setup!