Unitech / pm2-deploy

Deploy part of PM2
http://pm2.keymetrics.io/docs/usage/deployment/
MIT License
178 stars 72 forks source link

Fix always deploy to default branch problem #162

Closed ldarren closed 5 years ago

ldarren commented 5 years ago

this PR is an update of https://github.com/Unitech/pm2-deploy/pull/160

this PR fixed the broken $ pm2 deploy production

the fix will do a simple fast-farward if ref exists in remote server

Unitech commented 5 years ago

Tested it work well. Thank you! Will handle the change of the branch in the deploy part of ecosystem.json? Like switching from production branch to development branch?

Unitech commented 5 years ago

i get the error

  ○ running setup
  ○ cloning git@github.com:keymetrics/wakanda-hydroplant.git
/home/unitech/keymetrics/pm2-deploy/deploy: line 218: test: !=: unary operator expected
  ○ fast fetch
Cloning into '/var/wakanda-hub/source'...
Host key verification failed.

When running pm2 deploy production setup any clue on that?

ldarren commented 5 years ago

@Unitech i have tested it with ref in ecosystem.json and ref command line options. I haven't tested with branch field in ecosystem.json. is it documented?

ldarren commented 5 years ago

@Unitech please try pm2 deploy production setup again

KoteKotlyarov commented 5 years ago

So, pm2-deploy now 'pulls' code instead of 'reset --hard'.

But why not give us 2 solutions ? Current solution is good when branch can be fast forwarded and easily pulled. But what to do when branch can't be fast forwarded and need to be reseted ?

ldarren commented 5 years ago

may i know what is your use case? local changes at remote server that required reset —hard?

KoteKotlyarov commented 5 years ago

may i know what is your use case? local changes at remote server that required reset —hard?

Yes, it can be local changes on remote server. Person from other team can do some changes to test.

But we have another use case. Our git flow is built around rebase logic. We're preparing production branch and then rebase each %brand%/production upon production. In additional each %brand%/production contains commits. So trying to pull branch in our flow which was rebased will lead to mess of conflicts.

Currently I forked pm2-deploy and add old 'deploy' method which executes by default. Then forked pm2 to point into my pm2-deploy fork. Just a temporary fix to be able to deploy our apps :)

ldarren commented 5 years ago

@KoteKotlyarov i feel your pain. have you considered you tag for deployment?

example

{
   "apps" : [{
      "name" : "HTTP-API",
      "script" : "http.js"
   }],
   "deploy" : {
     // "production" is the environment name
     "production" : {
       "user" : "ubuntu",
       "host" : ["192.168.0.13"],
       "ref"  : "tags/prod-v1.0.0",
       "branch"  : "v1.0.0", // your tags will be branch out and named as "v1.0.0"
       "repo" : "git@github.com:Username/repository.git",
       "path" : "/var/www/my-repository",
       "post-deploy" : "npm install; grunt dist"
      },
   }
}

for more details https://github.com/Unitech/pm2-deploy/blob/master/deploy#L262-L276

KoteKotlyarov commented 5 years ago

Hi @ldarren ,

I knew that. But we don't want to update deploy file on each deployment. We're thinking about changing our Git Flow.

For now, to deploy specific branch we can do: pm2 deploy %file% %env% ref %branch%

I.e.: pm2 deploy deployment.json test ref origin/mybrand/hotfix

ldarren commented 5 years ago

@KoteKotlyarov can you try this?

pm2 deploy deployment.json test ref tags/prod-v1.0.0

or

pm2 deploy %config_file% %env% ref %branch or tags%
KoteKotlyarov commented 5 years ago

@ldarren Yes, I have successfully deployed specified branch.