Command "migration:show" should not return a non-zero exit code when there are unapplied migrations

[glen-84]

Issue Description

The migration:show command is returning a non-zero exit code when there are unapplied migrations, but this behaviour makes no sense, especially outside of a CI environment.

It should return a 0 exit code by default, and a CLI argument could be used to force a non-zero code.

Expected Behavior

Clean output with no errors (i.e. the exit code should be 0 by default).

Actual Behavior

If I simply wish to view a list of migrations, I get the following output:

> @x/api@1.0.0 typeorm D:\Programming\Projects\x\v4\api
> ts-node ./node_modules/typeorm/cli.js "migration:show"

query: SELECT * FROM `INFORMATION_SCHEMA`.`COLUMNS` WHERE `TABLE_SCHEMA` = 'x' AND `TABLE_NAME` = 'migrations'
query: SELECT * FROM `x`.`migrations` `migrations`  ORDER BY `id` DESC
 [ ] testIng1612699019592
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! @x/api@1.0.0 typeorm: `ts-node ./node_modules/typeorm/cli.js "migration:show"`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the @x/api@1.0.0 typeorm script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\Glen\AppData\Roaming\npm-cache\_logs\2021-02-07T12_13_13_421Z-debug.log

This is a mess. It's difficult to even see the list of migrations.

Steps to Reproduce

1. Create a migration.
2. Run the migration:show command.

My Environment

Dependency	Version
Operating System	Windows 10
Node.js version	v14.15.4
Typescript version	v4.1.3
TypeORM version	v0.2.30

Additional Context

#4173 (comment)
#4173 (comment)
#4173 (comment)

Relevant Database Driver(s)

• aurora-data-api
• aurora-data-api-pg
• better-sqlite3
• cockroachdb
• cordova
• expo
• mongodb
• mysql
• nativescript
• oracle
• postgres
• react-native
• sap
• sqlite
• sqlite-abstract
• sqljs
• sqlserver

Are you willing to resolve this issue by submitting a Pull Request?

• Yes, I have the time, and I know how to start.
• Yes, I have the time, but I don't know how to start. I would need guidance.
• No, I don't have the time, although I believe I could do it if I had the time...
• No, I don't have the time and I wouldn't even know how to start.

/cc @Juddling

[FlawaCLV]

Same issue. How did you manage to solve this ?

[glen-84]

I haven't yet. A PR should be created that moves this behaviour behind a CLI argument. It would be a breaking change, but it seems very wrong to me as it is now.

[jeffminsungkim]

I'm having the exact same issue!!!!

[stelescuraul]

This one applies for postgres at least as well.
I can make the changes required here, however I would consider them breaking changes since some people (myself included) rely on this to fail on CI/CD pipelines.
We can fix this and not be a breaking change if we add checks for CI environment. Eg:

• if not production or CI, exit with status 0.
• if prod / CI env, keep the current behaviour (exist with status 1).

Maybe we can even throw a custom error ? Something like MigrationsPendingError instead of code ELIFECYCLE ?

@imnotjames thought ?

[satma0745]

Same issues for postgres

[coolboy0961]

same issue here.(postgres)