`psql` outputs it's `NOTICE` messages to stderr causing the action to fail

[paw-eloquent-safe]

psql outputs it's NOTICE messages to stderr causing the whole action to fail even if the exit code is 0.
The offending lines of code:

postgresql/src/PsqlFilesExecutor.ts

Lines 27 to 33 in f82d2b2

	const options: any = {
	listeners: {
	stderr: (data: Buffer) => {
	error += data.toString();
	}
	}
	};

postgresql/src/PsqlFilesExecutor.ts

Lines 38 to 40 in f82d2b2

	if (error) {
	throw new Error(`error in file: ${file}\n${error}`);
	}

NOTICE's should be treated as warnings not errors those would be EXCEPTION's.

Maybe there should be an option for choosing to ignore stderr and instead rely on the exit code of psql

It's trivial to get a NOTICE to fail the action.
Consider the following output generated by dotnet ef migrations script -s Proj.Bootstrap -p Proj.Data --idempotent -o migration.sql:

CREATE TABLE IF NOT EXISTS "__EFMigrationsHistory" (
    "MigrationId" character varying(150) NOT NULL,
    "ProductVersion" character varying(32) NOT NULL,
    CONSTRAINT "PK___EFMigrationsHistory" PRIMARY KEY ("MigrationId")
);

START TRANSACTION;
....
COMMIT;

If the __EFMigrationsHistory table already exists, the action fails, because psql:/migration.sql:5: NOTICE: relation "__EFMigrationsHistory" already exists, skipping gets written to stderr.

[cotzo]

any updates on this issue? this is blocking any attempt to use this action for EntityFramework migrations

[MagnusSandgren]

I am experiencing the same issue. @k-visscher / Cotofana Radu (@cotzo) - what did you guys do as a workaround? 🙂

[cotzo]

Nothing you can do but set "continue-on-error: true" on the action step

[MagnusSandgren]

Ah well, that's mildly terrifying 😅 I would like the workflow to fail if the migration fails. Thanks for the response Cotofana Radu (@cotzo) 🙂

[MagnusSandgren]

Hopefully the issue will be resolved someday, until then I've created a verbose workaround for those interested 🙂

- name: Fetch runners public IP
  id: ip
  uses: haythem/public-ip@v1.3

- name: Open postgre firewall for migrations
  run: >
    az postgres flexible-server firewall-rule create 
    --rule-name GithubActions 
    --name ${{env.PostgresServerName}}
    --resource-group ${{env.AzureResourceGroup}}
    --start-ip-address ${{ steps.ip.outputs.ipv4 }}

- name: Apply EF migration script
  run: psql -f ./migrate.sql -q ${{ secrets.PSQL_CONNECTIONSTRING }}

- name: Close postgre firewall
  if: ${{failure() || success()}} # <= Make sure to delete the firewall rule regardless of the migration result
  run: >
    az postgres flexible-server firewall-rule delete 
    --rule-name GithubActions 
    --name ${{env.PostgresServerName}}
    --resource-group ${{env.AzureResourceGroup}}
    --yes

The secrets.PSQL_CONNECTIONSTRING is formated as follows: host=MyHost.postgres.database.azure.com port=5432 dbname=postgres user=postgres password=password sslmode=require.

[paw-eloquent-safe]

I am experiencing the same issue. @k-visscher / Cotofana Radu (@cotzo) - what did you guys do as a workaround? 🙂

I went the ontinue-on-error: true YOLO route, that Cotofana Radu (@cotzo) also suggested, the project was small enough that I could afford to manually check every now and then if the step actually succeeded or not.

[MagnusSandgren]

After further inspection of the code, it looks to me like the entire if block in PsqlFilesExecutor.ts can be, and should be removed. I believe this to be the case because the exec option IgnoreReturnCode is false by default and not overwritten by this repo. Meaning if the psql command returns with a return code other than 0, the exec package will create, and reject the promise with the error.

In other words - the if block will only trigger if the command writes to stderr and returns 0. However, if the command returns something other than 0, the error will flow right past the if block.

[seryckd]

Same problem here, NOTICES causing the action to fail. It would be preferred that only the exit code should be checked.

The workaround I am using is to disable writing notices by adding this to the top of the SQL file.

SET client_min_messages TO WARNING;

It's not ideal, and I may need to use the workaround provided by Magnus Sandgren (@MagnusSandgren).

[mehradn7]

Hi Balaga Gayatri (@BALAGA-GAYATRI) aksm-ms Microsoft Open Source (@microsoftopensource) Usha N (@N-Usha) Amruta Kawade (@AmrutaKawade) Kanika Pasrija (@kanika1894), can we have a status about this issue and more generally about this repository? Is it still being maintained? There are some pending issues such as this one, and the last commit dates back to 1 year ago so it would be great to know if we should wait for a fix or consider other alternatives.

Thanks!