forge create --verify is incompatible with --json, gives mixed output

[hbarcelos]

Component

Forge

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

forge 0.2.0 (123ad0a 2022-06-13T00:06:50.866238846Z)

What command(s) is the bug in?

forge create

Operating System

Linux

Describe the bug

This is the stdout of a forge create --verify ... execution:

No files changed, compilation skipped
Deployer: 0x...
Deployed to: 0xa258a4e6fdfc57e6b4a7295a0d42389a02d7a4d5
Transaction hash: 0x858....
Starting contract verification...
Waiting for etherscan to detect contract deployment...

Submitting verification for [lib/dummy-token/src/DummyToken.sol:DummyToken] 0xa258a4e6fdfc57e6b4a7295a0d42389a02d7a4d5.

Submitting verification for [lib/dummy-token/src/DummyToken.sol:DummyToken] 0xa258a4e6fdfc57e6b4a7295a0d42389a02d7a4d5.

Submitting verification for [lib/dummy-token/src/DummyToken.sol:DummyToken] 0xa258a4e6fdfc57e6b4a7295a0d42389a02d7a4d5.

Submitting verification for [lib/dummy-token/src/DummyToken.sol:DummyToken] 0xa258a4e6fdfc57e6b4a7295a0d42389a02d7a4d5.

Submitting verification for [lib/dummy-token/src/DummyToken.sol:DummyToken] 0xa258a4e6fdfc57e6b4a7295a0d42389a02d7a4d5.
Submitted contract for verification:
	Response: `OK`
	GUID: `kqb3ggyidyhyqfidigjyydryfkkz8kpr81eccy5uhhnjqxbqcx`
	URL: https://goerli.etherscan.io/address/0xa258a4e6fdfc57e6b4a7295a0d42389a02d7a4d5
Waiting for verification result...

This makes it very hard to compose the output with other commands (i.e.: store the new contract address into a variable).

It would be good if all of that was sent to stderr instead and produce only the contract address in stdout.

[tynes]

There is a --json argument that could help here

[mattsse]

@rkrasiuk
I believe these are repeated outputs from within the retry, right?

Submitting verification for [lib/dummy-token/src/DummyToken.sol:DummyToken] 0xa258a4e6fdfc57e6b4a7295a0d42389a02d7a4d5.

Submitting verification for [lib/dummy-token/src/DummyToken.sol:DummyToken] 0xa258a4e6fdfc57e6b4a7295a0d42389a02d7a4d5.

Submitting verification for [lib/dummy-token/src/DummyToken.sol:DummyToken] 0xa258a4e6fdfc57e6b4a7295a0d42389a02d7a4d5.

Submitting verification for [lib/dummy-token/src/DummyToken.sol:DummyToken] 0xa258a4e6fdfc57e6b4a7295a0d42389a02d7a4d5.

Submitting verification for [lib/dummy-token/src/DummyToken.sol:DummyToken] 0xa258a4e6fdfc57e6b4a7295a0d42389a02d7a4d5.

If so, I think we can skip that and instead implement are spinner or something?

@hbarcelos we need to wait until etherscan finished the job and the. way it works is by querying the status of the GUID.

[rkrasiuk]

yup, the repeated logs are caused by the retries, because etherscan doesn't pick up a newly deployed contract for a while. i see they were added at this commit. @joshieDo do u mind if we remove those and do a spinner as @mattsse suggested?

[hbarcelos]

The problem is not the logs being displayed, but they being sent to stdout instead of stderr.

I've created a small wrapper to workaround:

forge-deploy() {
  local RESPONSE=
  # Currently `forge create` send the logs to stdout instead of stderr.
  # This makes it hard to compose its output with other commands, so here we are:
  # 1. Duplicating stdout to stderr through `tee`
  # 2. Extracting only the address of the deployed contract to stdout
  RESPONSE=$(forge create --keystore="$FOUNDRY_ETH_KEYSTORE_FILE" "$PASSWORD_OPT" --json "$@" | tee >(cat 1>&2))

  jq -Rr 'fromjson? | .deployedTo' <<<"$RESPONSE"
}

This sends everything to stderr and outputs only the deployed contract address to stdout.

If you are adding a spinner, please make sure to use stderr, otherwise things like:

TOKEN=$(forge create ERC20 --constructor-args 'My Token' 'TOK' 18)

won't work.

[joshieDo]

@rkrasiuk for sure, go ahead

[zerosnacks]

I'm of the opinion that all regular output should be rendered to stdout with stderr being reserved for warnings and errors. To chain the output into other processes one should rely on the --json flag.

Currently the --verify flag is still incompatible w/ --json which is incorrect

Reference:

{"deployer":"0xDCC004c7Cd4275E9b83106F609163095670700db","deployedTo":"0x78338De128a15F1F3c32E07E8977893eDcADe111","transactionHash":"0x9436af54bc01f0dc64dd6320b2197fb1536b660d2776bcc1dd3531271e12e68a"}
Starting contract verification...
Waiting for etherscan to detect contract deployment...
Start verifying contract `0x78338De128a15F1F3c32E07E8977893eDcADe111` deployed on sepolia

Submitting verification for [src/Counter.sol:Counter] 0x78338De128a15F1F3c32E07E8977893eDcADe111.

Submitting verification for [src/Counter.sol:Counter] 0x78338De128a15F1F3c32E07E8977893eDcADe111.

Submitting verification for [src/Counter.sol:Counter] 0x78338De128a15F1F3c32E07E8977893eDcADe111.

Submitting verification for [src/Counter.sol:Counter] 0x78338De128a15F1F3c32E07E8977893eDcADe111.

Submitting verification for [src/Counter.sol:Counter] 0x78338De128a15F1F3c32E07E8977893eDcADe111.
Submitted contract for verification:
	Response: `OK`
	GUID: `6diymkthn7br6dqcqw43m5apz8zfmbggfzusmc7hrkylshjny7`
	URL: https://sepolia.etherscan.io/address/0x78338de128a15f1f3c32e07e8977893edcade111
Contract verification status:
Response: `NOTOK`
Details: `Pending in queue`
Contract verification status:
Response: `NOTOK`
Details: `Already Verified`
Contract source code already verified