Shortly after I added ‘Laravel Nova with your pipelines‘ I stumbled across a tweet on using an environment variable with composer. So instead of maintaining an auth.json file in the repository and using sed to replace placeholders, you can just add a COMPOSER_AUTH environment variable with the entire contents.

There had to be a better solution and here it was. Nice and simple.

If you use Laravel Nova, you undoubtedly were happy when Taylor started allowing us to use composer to install and update Nova. By doing so you create or edit your ~/.composer/auth.json file with something like the following:

{
    "http-basic": {
        "nova.laravel.com": {
            "username": "your-email@your-email.com",
            "password": "your-super-secret-token"
        }
    }
}

On your dev machine you need this file, along with your production or wherever you are building / deploying your site. Using forge, this is a simple git pull and not a complicated deployment.

I setup a GitLab pipeline so that when pushing the master branch, it will run my unit tests, then trigger forge to do the deployment.

To get composer to install and not error out means we had to add auth.json to our repository and in our build steps, copy it to the correct directory. By using variables, we don’t need to store our credentials in that file. Our auth.json is literally what we have above. We are going to replace your-email@your-email.com with our custom variable in the Gitlab CI/CD Environment Variables page.

Here is what our test stage looks like. The ‘- sed’ lines replace our placeholders in auth.json with the variables we defined above.

phpunit:

  stage: test

  script:
    - cp auth.json ~/.composer/auth.json
    - sed -i "s/your-email@your-email.com/${NOVA_COMPOSER_EMAIL}/g" ~/.composer/auth.json
    - sed -i "s/your-super-secret-token/${NOVA_COMPOSER_TOKEN}/g" ~/.composer/auth.json
    - composer install --prefer-dist --no-ansi --no-interaction --no-progress --no-scripts
    - cp .env.testing .env
    - php artisan key:generate
    - phpunit --colors=never

There may be a more elegant way to achieve this, but this works and doesn’t jump through too many hoops.

Was composer not able to find the mcrypt PHP extension? When I developing on my local machine I use XAMPP because it is easy to setup. I also tend to use Laravel for a lot of projects as well. If you are using the same, when doing a composer update you have no doubt encountered this error. Mcrypt PHP extension required.

Writing lock file
Generating autoload files
Mcrypt PHP extension required.
Script php artisan clear-compiled handling the post-install-cmd event returned with an error

It turns out there is an extremely easy way to fix this. Simply update your .bash_profile with the following text:

export PATH=/Applications/XAMPP/bin:$PATH

This will find the XAMPP version of PHP that has mcrypt installed first instead of the one that comes with OSX.

The .bash_profile file allows you to have user defined settings when using Terminal. If you want to user a different version of PHP, you can change it here. Do you want to setup shortcuts? A lot of people will create a shortcut so that ls -l can be run by typing ll.

To do that enter the following in your .bash_profile file.

alias ll="ls -l"

If for some reason you don’t have a .bash_profile, create it in your root user directory. If your username is jeff, the file will be /Users/jeff/.bash_profile.

After you have made your change you may need to source your profile. Execute the following command inside terminal to do it.

source ~/.bash_profile

Once this is done, you should be able to do a composer update without any errors occurring.

Image courtesy of Baitong333 / FreeDigitalPhotos.net

I am always looking for better ways of deploying me code. In the past I have used Fabric to create a deployment process. Although I use git, I have never used it for deployments. With Fabric I copied my code to another folder, did any processing such as removing files, or setting a environment variable and then uploaded the package. I was able to create versioning. Each deployment went to it’s own folder and symlinks to the document root were created. In the event the deployment gets botched I can easily login and re-link to the previous deployment.

On a new project I recently launched I have started using Capistrano. If you are a Laravel user check out this tutorial from TutsPlus.

Using Capistrano, I can run a command and it will rollback for me. With the default setup I have also switched to git based deployments. Both GitHub and Bitbucket allow you to enter deployment keys for your server. These are SSH keys but have read-only access to pull down the changes.

What I like with this approach is that the client side deployment script only relies on having access to the server. No longer am I defining paths where to copy files to if I have to deploy from my laptop versus my desktop.

What I don’t like is the “config” folder in my root project. It’s quite vague but I haven’t looked to see if I can change the name. One thing I am looking to do is write the release name to a php file so I can use it for things like cache busting.