Custom behaviour

[uLow]

Hi, Stephen!
Is there any way to override whole deployment process?

[REBELinBLUE]

Hmm, I mean you could overwrite the scripts in resources/scripts/steps what are you trying to do?

[uLow]

So there is no GUI way to do this?

P.S. Consider this as feature request. So expected behavior is to have a "templates" for deployment flow. Default two - "as it is now" and "blank/custom". In custom mode you can override/re-use some steps from default one.

[REBELinBLUE]

Maybe there is some misunderstanding. What is it you want to change about the 4 default steps? They are simply clone the repository, install composer dependencies (which only runs if there is a composer.json file present), activate the new release and clean up old releases.

Just checking, you know that on the "Commands" tab of a project you can add additional commands to run before and/or after each of those 4 steps?

[uLow]

It may sound like I'm going to do something wrong, but when you have a docker image (and DON'T want to use other tools), you may want to skip "git clone", having whole code in your container. The only job for deployer is to implement "blue/green deployment" process with that containers without worrying about the code.

Of course there are other tools and frameworks to achieve this, but then it would grow into to another zoo. IMHO if deployer is able to help with this problem within few steps, what is the reason to not do it? We don't need to have another deploy system.

[REBELinBLUE]

Makes sense I think. So what commands are you wanting to run with deployer?

[uLow]

In fact - any. It would be even enough to be able to disable some steps. Thats all.

[mbouclas]

I second that. Running composer install right after the first pull is a nightmare in some projects as additional steps might be needed before running this command is safe.

Maybe you're missing the .env or some other weird configuration, or maybe running composer install triggers other commands from dependencies, but your app is not 100% setup, in which case composer will fail.

So, having the composer install step as optional, especially on the first deployment, is a huge bonus

[REBELinBLUE]

But in that scenario you can add additional commands to the "after" step for clone new release and/or "before" step for install dependencies. Using the files tab you can create a configuration file such as .env which is created before running composer

[mbouclas]

true, but i have stumbled upon 2-3 cases where this will not cut it as the "pre-configuration" is a bit more complicated. Sure, you could hack a bunch of scripts and have them execute before, but usually in these cases you want to go through console and get done with it.

I could agree that these are kind of edge cases though and if you stumble upon them, well tough. Having the option to omit a step in the first deployment would make things, not as tough.

[uLow]

"Hack" is right word here. It really starts headache in specific projects or even in specific workflow.
IMHO this "feature" development takes drastically less time than hacking around for projects with such workflow.