Hello,

In some cases a server doesn't have a root user, and in order to deploy with Magallanes, an user with sudo permissions is needed (e.g. where I work because a security policy servers shouldn't have a root user). Maybe it is not an ideal scenario, but sometimes as a developer you have to manage with this kind of restrictions. So I have added a new option (use-sudo) to execute all deployment commands as sudo. The activation of this option is straightforward, and by default is set to false:

deployment:
  user: foo
  use-sudo: true

I've changed the TarGzTask too. Because you can't do an scp to a folder wich needs sudo permissions, when use-sudo is enabled, the tar.gz is previously uploaded to /tmp and after that it is moved to the right destination.

I hope you can find it useful :)

Regards

NOTE: Related issues: #111

Hi, I am trying a git rebase strategy and according to a log and from what I checked in the code it seems that during git rebase strategy a directory for the release is not created. Here is start of the log for last release.

2015-01-23 11:10:38 -- Starting Magallanes--------------
2015-01-23 11:10:38 -- Logging enabled $ ssh  -p 22 -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no [email protected] "sh -c
2015-01-23 11:10:38 -- Logging enabled: /path/to/app/.mage/logs/log-20150123-111038.log
2015-01-23 11:10:38 -- Deploy summary
2015-01-23 11:10:38 -- Environment: production----------
2015-01-23 11:10:38 -- Release ID:  20150123111038------
2015-01-23 11:10:38 -- ---- Executing: $ rm /tmp/magefnXdW5 /tmp/magefnXdW5.tar.gz
2015-01-23 11:10:38 -- No Pre-Deployment tasks defined.
2015-01-23 11:10:38 -- Deploying to server.com
2015-01-23 11:10:38 -- Running Deploy via Git Rebase [built-in] ...
2015-01-23 11:10:38 -- Run remote command cd /var/www/app && cd releases/20150123111038 && git fetch origin
2015-01-23 11:10:38 -- ---------------------------------path/to/app/releases/20150123111533 && app/console cache:clear --env=prod --no-warmup
2015-01-23 11:10:38 -- ---- Executing: $ ssh  -p 22 -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no [email protected] "sh -c
\"cd /var/www/app && cd releases/20150123111038 && git fetch origin\""=/dev/null -o StrictHostKeyChecking=no [email protected] "sh -c
2015-01-23 11:10:38 -- sh: line 0: cd: releases/20150123111038: No such file or directoryo-warmup\""

Folder 20150123111038 isn't created and deployment failed.

I think it would be very handy if we can combined magallanes with gitflow and use git tag to deploy a release.

for example I tag my master branch with v1.2.3, then I deploy this tag to production using

bin/mage deploy --release=v1.2.3 to:dev

Is there a workaround to make such a thing?

Really nice tool by the way.

Hey, As I mentioned in #159 , I've done some fixes and corrections for PHPUnit test environment for Magallanes. I've also noticed and fixed following problems:

• lack of phpunit in bin directory while doing installing dependencies by composer. I've fixed that by adding bin-dir to composer.json
• no colors... for phpunit output :) Changed phpunit default configuration in phpunit.xml.dist
• coverage - I've added coversDefaultClass and covers in test class to be sure that those test methods test that what we want to test

Please free to code-review! @SenseException @andres-montanez

PS. Sorry, I had to close previous PR, because I accidentally compared it to master branch again :(

Hey there,

What (if any) is the policy about creating custom tasks, for multiple projects? These can not be placed with the project, it would be better to place them in the Magallanes folder.

This works if I create a custom folder in BuiltIn and put them there. However, that is not preferable when working with version control, ie git.

Can you add a default folder next to BuiltIn, maybe called Global, whose contents have a git ignore? Or does anyone have a better idea?

I would like to hear your thoughts!

Hi devs! Recently I've noticed there is abandoned #160 issue, however I think this is gonna be useful for many of Magallanes users.

• Environent variables can be set by passing options to general config...

# .mage/config/general.yml
name: My fantastic App
email: [email protected]
env:
  variables:  
    node_path: "/bin/node"
    symfony_env: prod

• ... or environment config...

# .mage/config/environment/production.yml
deployment:
  user: root
  from: ./
  to: /var/www/vhosts/example.com/www
env:
  variables:
    symfony_env: prod

• ... or even task config!

# .mage/config/environment/production.yml
tasks:
  pre-deploy:
    - scm/update
  on-deploy:
    - symfony2/cache-warmup: { env: prod, env: { variables: {env1: key1} } }
  # short way
    - symfony2/cache-warmup: { env: prod, env.variables: {env1: key1} }

When you run the command, the set variables are prepended to the original command:

$ SYMFONY_ENV=prod composer install

(Note: The script does not uppercases variables, they're gonna be passed in the same way you typed them in config)

Given variables have the following priorities:

• Task parameters and command line parameters
• Environment config parameters
• General config parameters

That means, if you have the env variable in your task configuration and there's an env var in your environment configuration, the task's one will override the environment's config.

The scripts allows also to prepend all system's environment variables, but it needs proper setting in your php.ini for CLI:

# php.ini
variables_order="EGPCS"

Then, you can set your settings from .bashrc or .zshrc, like:

# .zshrc
export NODE_PATH="bin/node"

System's env variables has the lowest prority to give you ability to override them in config.

Warning: Including system's environment variables can slow down the applicattion, so use it carefully. Feel free to review and comment! I know there's gonna be do much more, all sugestions are welcome!

I'm not sure this is the right place to start this up as there is a MagallanesSite repository where the documentation is today but i feel like i'll have more feedback here, so here i am.

I wanted to start by saying i really like the website it exposes very clearly the basics of how Mage works and how basic configurations can be done.

That said, it becomes a lot more frustrating when you're trying to use built-in tasks for example. As any young project it is understandable that not everything is well documented and most people are used to go have a look at the code to have a better understanding of how it works. The problem for tasks is that they're not easy to read and more importantly it is difficult to see how they can be configured with specific parameters.

I'd like to help, hopefully with some task contributors, to improve this. What i see here is 2 different things to do :

1. Documentation : It should be updated with the last PR's improvements and also each task contributor should also contribute to its documentation. We could provide a default template for a documented task to make it more easy.
2. Contributor guidelines : We should encourage common good practices in order to have a consistent application. Today each contributed task is written a bit differently, there are arguments that are camel cased, others lower cased etc... Tasks code is not much documented either. This guide should address this so people reading the code could figure out more easily what it is doing. We shouldn't forget that we're dealing with deployment here, a very sensitive task when it comes to production. Users should easily find out how everything works.

To conclude, i feel that Mage is a very underestimated product and i think that contributing to these 2 things is going to definitely improve Mage adoption. That, and unit tests of course ;)

Any input on this ?

I was reviewing the project code to check which classes can be tested easily (#44), but I'm afraid there will be bigger refactoring steps in the future before many classes of the project can be tested.

For now, I contribute small tests of the command factory, creating build in and custom commands. For custom commands, I created some dummy commands to be able to check exceptions and returned command instances.

I guess next time will be a PR with refactored code.

user@host:/home/user/jenkins/builds$ mage deploy to:production
Starting Magallanes
    Logging enabled: /home/user/jenkins/builds/.mage/logs/log-20140919-122423.log

    There is already an instance of Magallanes running!

Finished Magallanes

and if echo last returned code, i get 0

user@host:/home/user/jenkins/builds$ echo $?
0

next case

user@host:/home/user/jenkins/builds$ mage deploy to:production
Starting Magallanes
    Logging enabled: /home/user/jenkins/builds/.mage/logs/log-20140919-123408.log

    Deploy summary
        Environment: production
        Release ID:  20140919123408

    Starting Pre-Deployment tasks:
        Running Start composer ... OK
    Finished Pre-Deployment tasks: 1/1 tasks done.


    Deploying to 10.101.100.254:22
        Running Deploy via Rsync (with Releases) [built-in] ... FAIL
        Running Make Shared Folder ... FAIL
    Deployment to 10.101.100.254:22 completed: 0/2 tasks done.


    A total of 2 deployment tasks failed: ABORTING

    No Post-Deployment tasks defined.


    Time for deployment: 3 minutes 9 seconds.
    Average time per host: 3 minutes 9 seconds.
    Total time: 3 minutes 11 seconds.

Finished Magallanes

returned

user@host:/home/user/jenkins/builds$ echo $?
0

and My CI server with jenkins, sends to me message about successful build.

Adds the filesystem\permissions task to allow change of permissions on given paths. Change will be done on local or remote host depending on the stage of the deployment. Usage could be :

   on-deploy:
     - filesystem/permissions:
         paths:
             - /var/www/myapp/app/cache
             - /var/www/myapp/app/logs
         recursive: false
         checkPathsExist: true
         owner: www-data:www-data
         rights: 775

Also adds the task filesystem\permissions-writable-by-web-server wich extends filesystem\permissions with default values in order to give web server user rights to write on given paths. Usage could be :

   on-deploy:
     - filesystem/permissions-writable-by-web-server:
         paths:
             - /var/www/myapp/app/cache
             - /var/www/myapp/app/logs
         recursive: false
         checkPathsExist: true

Finally, i added a last task filesystem/permissions-readable-only-by-web-server that also extends filesystem\permissions but this time in order to give only to web server user read permissions on given paths. Usage could be :

   on-deploy:
     - filesystem/permissions-readable-only-by-web-server:
         paths:
             - /var/www/myapp/app/config/config.yml
             - /var/www/myapp/app/config/parameters.yml
         recursive: false
         checkPathsExist: true

Hey Andres,

I know this is rather a question but I just can't figure out the issue and I'm so confused now that I thought i'd just submit an issue and maybe you know why this isn't working immediately :-D

I have a task that writes updated content to my Symfony parameters.yml during the on-deploy stage. In Mage v1 this worked perfectly fine like this:

$this->runCommandRemote("echo " . escapeshellarg($content) . " > app/config/parameters.yml");

I tried the very same for Nostromo but it just doesn't want to work in whatever way I try to get it to work :-(

$process = $this->runtime->runRemoteCommand(
    sprintf('echo %s > app/config/parameters.yml', escapeshellarg($content)),
    true
);

The error message in the log file is the following:

bash: -c: line 0: unexpected EOF while looking for matching `"' bash: -c: line 8: syntax error: unexpected end of file

I noticed that you wrapped the whole sh -c command in " in v1 (https://github.com/andres-montanez/Magallanes/blob/1.0/Mage/Task/AbstractTask.php#L209) but you don't do this anymore in v3 anymore: https://github.com/andres-montanez/Magallanes/blob/master/src/Runtime/Runtime.php#L428

Is this due to something the Symfony Process component does internally? Or do you see why this is not working? Thank you for your help, really appreciate it :-)

With Symfony 6.1, we have the following error when installing the library :

andres-montanez/magallanes 5.0.0 requires monolog/monolog ^2.5 -> found monolog/monolog[2.5.0, 2.6.0, 2.7.0, 2.8.0] but the package is fixed to 3.1.0 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.