PHPackages                             aes3xs/yodler - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [DevOps & Deployment](/categories/devops)
4. /
5. aes3xs/yodler

Abandoned → [aes3xs/tasker](/?search=aes3xs%2Ftasker)Library[DevOps & Deployment](/categories/devops)

aes3xs/yodler
=============

Task automation tool

01.6kPHP

Since Feb 25Pushed 8y ago1 watchersCompare

[ Source](https://github.com/aes3xs/tasker)[ Packagist](https://packagist.org/packages/aes3xs/yodler)[ RSS](/packages/aes3xs-yodler/feed)WikiDiscussions master Synced 1mo ago

READMEChangelogDependenciesVersions (1)Used By (0)

Tasker
======

[](#tasker)

Tasker is an automation tool to write small and simple deploy scripts.
It's suitable for one-server projects without CI integrations.
If you want more, please take a look at Jenkins, TeamCity and other tools. It's not pretent to replace them. Tasker inspired by Deployer project, you can also take a look for it. Tasker is designed to be more flexible (overridable) and more object-oriented, but less featured.

Installation
------------

[](#installation)

Install from composer
`composer require aes3xs/tasker`

How to deploy
-------------

[](#how-to-deploy)

A good way to go will be splitting deployment into local and remote parts.

Local part prepares code, warms up file caches, downloads vendors and other operations, which affects everything *inside* project dir.
No external dependencies, services or files (except vendor managers and php itself).
No database requests, no migrations.
This script can be executed everythere, on build server or local machines. It creates ready-to-deploy module which can be copied and run on production as is.
It's pretty useful to have such script in project and it should't have dependencies, such as composer. Because it's responsible to run it, if you have bare broject from repo.
Some of these steps sometimes defined in composer.json scripts section. But I prefer to have standalone file.

Here is an example (./bin/deploy):

```
#!/bin/bash

set -e
set -o pipefail

SYMFONY_ENV=${SYMFONY_ENV:="dev"}
SYMFONY_DEBUG=${SYMFONY_DEBUG:="1"}
for i in "$@"; do case $i in -e=*|--env=*) SYMFONY_ENV="${i#*=}"; shift;; --no-debug) SYMFONY_DEBUG="0"; shift;; *);; esac done

ROOT="$(dirname "$(dirname "$(readlink -fm "$0")")")"
PHP=$(which "php") || { echo "PHP is not found" ; exit 1; }
YARN=$(which "yarn") || { echo "Yarn is not found" ; exit 1; }
COMPOSER=$(which "composer") || { echo "Composer is not found" ; exit 1; }
if [ "$SYMFONY_DEBUG" == "0" ]; then NO_DEBUG="--no-debug"; fi
CONSOLE="${ROOT}/bin/console --quiet --env=${SYMFONY_ENV} ${NO_DEBUG}"

echo "SYMFONY_ENV   = ${SYMFONY_ENV}"
echo "SYMFONY_DEBUG = ${SYMFONY_DEBUG}"
echo "PROJECT_ROOT  = ${ROOT}"
echo "PHP           = ${PHP}"
echo "YARN          = ${YARN}"
echo "COMPOSER      = ${COMPOSER}"
echo "CONSOLE       = ${CONSOLE}"
echo ""

_exec () {
   echo -e "\033[1m[$(date +%T)] >\033[0m" $1
   eval $1
}

# Vendors
_exec "cd ${ROOT} && ${COMPOSER} install --prefer-dist --no-progress --no-interaction --optimize-autoloader"
_exec "cd ${ROOT} && ${YARN} install --prod --non-interactive"

# Cache
_exec "rm -rf ${ROOT}/var/cache/${SYMFONY_ENV}"
_exec "chmod 0775 ${ROOT}/var/cache"
_exec "${CONSOLE} cache:warmup"

# Assets
PATHS=(
"${ROOT}/web/js"
"${ROOT}/web/css"
"${ROOT}/web/bundles"
)
_exec "rm -rf ${PATHS[*]}"
_exec "${CONSOLE} assets:install ${ROOT}/web --symlink --relative"
_exec "${CONSOLE} assetic:dump ${ROOT}/web"

# Writable
_exec "if [ ! -w ${ROOT}/var/cache ]; then { echo 'Is not writable' ; exit 1; }; fi"
_exec "if [ ! -w ${ROOT}/var/logs ]; then { echo 'Is not writable' ; exit 1; }; fi"
_exec "if [ ! -w ${ROOT}/var/spool ]; then { echo 'Is not writable' ; exit 1; }; fi"
```

You can also write this with Tasker, but I'd suggest to keep separate shell script.

Remote part of deployment process works with external services, such as nginx, php-fpm, databases.
Also you must have access to project repository to clone it.

There are few important things.

First, executing commands from another user.
For security reasons, each person on server must have it's own credentials.
But project itself configured to work from one user, for example, `www-data`.
So you must add something like `sudo -u USER` to each call, and it's already implemented.

Second, authentication to clone repo on server.
GitLab has login/pass option or public key, for example.
So better way to use key to SSH, and same key to authenticate to GitLab, or another system.
This can be done with SSH forwarding authentication.

Deploy script example

```
#!/usr/bin/env php