wrong data in pm2 jlist property versioning #3276
Comments
|
You must set the |
|
So this is the configuration for one of our apps used in the webhook to redeploy: CP3_PRD: {
branches: ["master"],
command: "./deploy.sh master CP3_PRD",
events: ["push"],
exit: false,
group: "node",
options: {
cwd: "/opt/fnode",
env: {
NODE_ENV: "production",
},
},
token: ".............................. ;o) ................................",
user: "node",
},cwd points to the directory where the repository of that appropriate app got cloned to. That should be correct then for my understanding. in the webhook logic, we set the process environment then as follows: tpl.options.env = Object.assign({}, process.env, tpl.options.env);//tpl corresponds to the config aboveand finally execute the command through child_process.exec: cp.exec(tpl.command, tpl.options, (err, stdout, stderr) => {
//handling of the callback results
});Basically, I don't see there an issue? I mean, everything is restarting and working fine, just not these data fields. |
|
Ehm.. can |
|
No, not the case. I've started our port 80 to 443 forwarding app manually: all data in these fields looked fine. triggered redeployment via webhook app -> data broken. |
|
Do you need anything else @vmarchaud ? |
|
Looks like |
|
introduced because of: #2756 If I change I am asking myself what you suggest to be the right way here. I really have no clue. |
|
I'm pretty sure |
|
here's the pm2.json we use for our main app: {
"apps": [{
"name": "CP3PRD",
"script": "fnode.js",
"args": ["CP3_PRD"],
"error_file": "/var/log/frontend/CP3/err.log",
"out_file": "/var/log/frontend/CP3/out.log",
"instances": 0,
"cwd": "/opt/fnode",
"env": {
"NODE_ENV": "production"
},
"exec_mode": "cluster",
"exec_interpreter": "node",
"merge_logs": true,
"log_date_format": "YYYY-MM-DD HH:mm:ss Z",
"autorestart": true,
"restart_delay": 10000,
"watch": false,
"wait_ready": true,
"listen_timeout": 10000,
"kill_timeout": 20000
}]
}That's the config we use to start the application. So I cannot imagine cwd is the reason behind. |
|
I have the impression that pm2 itself reuses some options settings (which came from parent process and were generated for the webhook app) at least for the versioning part later on. Deployment itself seems to work correctly. So as, settings from the parent process seem to be required to have paths to npm, et al set correctly, maybe further things I am not aware of currently - I am asking myself which object keys from the options object need to be cleaned up to get this working? |
|
any further suggestions? |
|
No suggestion in this case it will need to be inspected by someone (feel free to do it and open up a PR to fix any issue) |
|
Thanks, as this goes very deep into pm2 architecture, I don't think I am able to cover this (and yes, I am very busy in addition). If I should get the time, yes I'll have an eye on it, but don't expect this to happen. |
|
Are there news on this issue? I would also recommend to get the "S: Open for PR" flag removed, as I won't get that time in near future. |
|
@Papakai this flag is not only for people who open issue, but for all people who want to contribute. |
|
@wallet77 thanks, good to know. Still leaves me the question when / if this might get reviewed. Or at least when to get some informations which environment data to explicitely drop to avoid this data issue. |
|
@Papakai we have a lot of work with the next release. I think we can check this one (and many other issues linked to versioning) after the next release. |
I called
pm2 jlist. In data property pm2_env.versioning I get data to another repository. In our case: our webhook repository which is used to trigger the deployment process and thus restarts the pm2 apps.For each of our pm2 apps we have this data covered in the above data property which doesn't make a lot sense. The purpose of that object data is imo to cover the versioning data of the app repository itself. I hope I am right here.
Our webhook creates always a new child process and executes the deployment script of the appropriate app. the child process always inherits the environment of the parent process.
Have we to change anything in our process or is this indeed a bug?
The text was updated successfully, but these errors were encountered: