n8n used to populate the environment variable N8N_VERSION (accessible in workflows as {{ process.env.N8N_VERSION }}) - but this seems to have been removed between or around versions 1.93.0 and 1.94.1
Is there a simple way to determine the current version of n8n from a workflow now? I use this to alert me when to update n8n upon a new LATEST release that is newer than my current version being available.
Cross-referencing with issue Version of Docker image - missing info · Issue #16129 · n8n-io/n8n · GitHub - this is slightly different but seems that the version was removed in another place as well, perhaps at the same time. I don’t believe the fix for that in 1.100 would add this environment variable back.
Thanks, that’s a reasonable enough (and obvious!) way to do so which I’ll use for now. But if it is available via the API or an env variable that would be great!
Nice! I like that, no extra (system) execution, and it’s pretty portable.
Hmm, actually - that path doesn’t seem to exist on the Docker image, since everything (maybe recently) got put in to specific paths. I’m not sure if you can predict the paths in this stack trace or maybe there’s something else that could be used?
Ironically, the version is actually returned as the first line in this error, but only when stop workflow is the error action - it is omitted from the return data if you opt to pass the error on as node output.
Error: Cannot find module '/usr/local/lib/node_modules/n8n/package'
at /usr/local/lib/node_modules/n8n/node_modules/.pnpm/@n8n+task-runner@file+packages+@[email protected][email protected][email protected][email protected]_/node_modules/@n8n/task-runner/dist/js-task-runner/require-resolver.js:16:27
at VmCodeWrapper (evalmachine.<anonymous>:1:247)
at evalmachine.<anonymous>:7:2
at Script.runInContext (node:vm:149:12)
at runInContext (node:vm:301:6)
at result (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@n8n+task-runner@file+packages+@[email protected][email protected][email protected][email protected]_/node_modules/@n8n/task-runner/dist/js-task-runner/js-task-runner.js:162:63)
at new Promise (<anonymous>)
at JsTaskRunner.runForAllItems (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@n8n+task-runner@file+packages+@[email protected][email protected][email protected][email protected]_/node_modules/@n8n/task-runner/dist/js-task-runner/js-task-runner.js:156:34)
at JsTaskRunner.executeTask (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@n8n+task-runner@file+packages+@[email protected][email protected][email protected][email protected]_/node_modules/@n8n/task-runner/dist/js-task-runner/js-task-runner.js:117:26)
at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
at async Object.waitingForSettings (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@n8n+task-runner@file+packages+@[email protected][email protected][email protected][email protected]_/node_modules/@n8n/task-runner/dist/task-runner.js:256:17)
at async TaskState.caseOf (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@n8n+task-runner@file+packages+@[email protected][email protected][email protected][email protected]_/node_modules/@n8n/task-runner/dist/task-state.js:56:16)
at async JsTaskRunner.receivedSettings (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@n8n+task-runner@file+packages+@[email protected][email protected][email protected][email protected]_/node_modules/@n8n/task-runner/dist/task-runner.js:250:9)
As mentioned in the initial post, I use this to determine if there is a newer available version from GitHub releases than the version I am currently running, so and if so I notify myself that an update is available.
Marked as such, the execute command option seems to be the safest, as the paths for the node libraries do not appear to consistent between environments/versions.
Marked as such, the execute command option seems to be the safest, as the paths for the node libraries do not appear to consistent between environments/versions.