`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