Our devs need a convenient way to run debug and debug-ext in the verbose mode, so I've created this PR to handle this.
VERBOSE variable can be enabled by:
uncomment in the Makefile
export VERBOSE=true in the current bash session
as a variable before the make run like VERBOSE=true make debug
Additionally, I've added explicit log saying that you are in verbose mode
Test
Example run:
$ VERBOSE=true make clean debug
...
Harmony (C) 2023. harmony, version v8408-v2024.2.0-12-g5ad7789d-dirty (uladzislau@ 2024-09-11T12:11:50+0300)
~/go/src/github.com/harmony-one/harmony/bin ~/go/src/github.com/harmony-one/harmony
~/go/src/github.com/harmony-one/harmony
[WARN] - running with verbose logs
...
example of DEBUG log is below:
{
"CGO_CFLAGS": "-I/home/uladzislau/.gvm/pkgsets/go1.22.5/global/src/github.com/harmony-one/bls/include -I/home/uladzislau/.gvm/pkgsets/go1.22.5/global/src/github.com/harmony-one/mcl/include",
...
}
Unit Test Coverage
Before:
<!-- copy/paste 'go test -cover' result in the directory you made change -->
After:
<!-- copy/paste 'go test -cover' result in the directory you made change -->
Test/Run Logs
Operational Checklist
Does this PR introduce backward-incompatible changes to the on-disk data structure and/or the over-the-wire protocol?. (If no, skip to question 8.)
YES|NO
Describe the migration plan.. For each flag epoch, describe what changes take place at the flag epoch, the anticipated interactions between upgraded/non-upgraded nodes, and any special operational considerations for the migration.
Describe how the plan was tested.
How much minimum baking period after the last flag epoch should we allow on Pangaea before promotion onto mainnet?
What are the planned flag epoch numbers and their ETAs on Pangaea?
What are the planned flag epoch numbers and their ETAs on mainnet?
Note that this must be enough to cover baking period on Pangaea.
What should node operators know about this planned change?
Does this PR introduce backward-incompatible changes NOT related to on-disk data structure and/or over-the-wire protocol? (If no, continue to question 11.)
YES|NO
Does the existing node.sh continue to work with this change?
What should node operators know about this change?
Does this PR introduce significant changes to the operational requirements of the node software, such as >20% increase in CPU, memory, and/or disk usage?
Issue
Our devs need a convenient way to run
debuganddebug-extin the verbose mode, so I've created this PR to handle this. VERBOSE variable can be enabled by:export VERBOSE=truein the current bash sessionVERBOSE=true make debugTest
Example run:
Unit Test Coverage
Before:
After:
Test/Run Logs
Operational Checklist
Does this PR introduce backward-incompatible changes to the on-disk data structure and/or the over-the-wire protocol?. (If no, skip to question 8.)
YES|NO
Describe the migration plan.. For each flag epoch, describe what changes take place at the flag epoch, the anticipated interactions between upgraded/non-upgraded nodes, and any special operational considerations for the migration.
Describe how the plan was tested.
How much minimum baking period after the last flag epoch should we allow on Pangaea before promotion onto mainnet?
What are the planned flag epoch numbers and their ETAs on Pangaea?
What are the planned flag epoch numbers and their ETAs on mainnet?
Note that this must be enough to cover baking period on Pangaea.
What should node operators know about this planned change?
Does this PR introduce backward-incompatible changes NOT related to on-disk data structure and/or over-the-wire protocol? (If no, continue to question 11.)
YES|NO
Does the existing
node.shcontinue to work with this change?What should node operators know about this change?
Does this PR introduce significant changes to the operational requirements of the node software, such as >20% increase in CPU, memory, and/or disk usage?
TODO