build(deps): bump @chainlink/contracts from 0.3.1 to 1.3.0 in /packages/network-contracts

[dependabot]

Bumps @chainlink/contracts from 0.3.1 to 1.3.0.

Release notes

Sourced from @​chainlink/contracts's releases.

v1.3.0

Added

• Added disk rotating logs. Chainlink will now always log to disk at debug level. The default output directory for debug logs is Chainlink's root directory (ROOT_DIR) but can be configured by setting LOG_FILE_DIR. This makes it easier for node operators to report useful debugging information to Chainlink's team, since all the debug logs are conveniently located in one directory. Regular logging to STDOUT still works as before and respects the LOG_LEVEL env var. If you want to log in disk at a particular level, you can pipe STDOUT to disk. This automatic debug-logs-to-disk feature is enabled by default, and will remain enabled as long as the LOG_FILE_MAX_SIZE ENV var is set to a value greater than zero. The amount of disk space required for this feature to work can be calculated with the following formula: LOG_FILE_MAX_SIZE * (LOG_FILE_MAX_BACKUPS + 1). If your disk doesn't have enough disk space, the logging will pause and the application will log Errors until space is available again. New environment variables related to this feature:
  • LOG_FILE_MAX_SIZE (default: 5120mb) - this env var allows you to override the log file's max size (in megabytes) before file rotation.
  • LOG_FILE_MAX_AGE (default: 0) - if LOG_FILE_MAX_SIZE is set, this env var allows you to override the log file's max age (in days) before file rotation. Keeping this config with the default value means not to remove old log files.
  • LOG_FILE_MAX_BACKUPS (default: 1) - if LOG_FILE_MAX_SIZE is set, this env var allows you to override the max amount of old log files to retain. Keeping this config with the default value means to retain 1 old log file at most (though LOG_FILE_MAX_AGE may still cause them to get deleted). If this is set to 0, the node will retain all old log files instead.
• Added support for the force flag on chainlink blocks replay. If set to true, already consumed logs that would otherwise be skipped will be rebroadcasted.
• Added version compatibility check when using CLI to login to a remote node. flag bypass-version-check skips this check.
• Interrim solution to set multiple nodes/chains from ENV. This gives the ability to specify multiple RPCs that the Chainlink node will constantly monitor for health and sync status, detecting dead nodes and out of sync nodes, with automatic failover. This is a temporary stand-in until configuration is overhauled and will be removed in future in favor of a config file. Set as such: EVM_NODES='{...}' where the var is a JSON array containing the node specifications. This is not compatible with using any other way to specify node via env (e.g. ETH_URL, ETH_SECONDARY_URL, ETH_CHAIN_ID etc). WARNING: Setting this environment variable will COMPLETELY ERASE your evm_nodes table on every boot and repopulate from the given data, nullifying any runtime modifications. Make sure to carefully read the EVM performance configuration guide for best practices here.

For example:

export EVM_NODES='
[
	{
		"name": "primary_1",
		"evmChainId": "137",
		"wsUrl": "wss://endpoint-1.example.com/ws",
    "httpUrl": "http://endpoint-1.example.com/",
		"sendOnly": false
	},
	{
		"name": "primary_2",
		"evmChainId": "137",
		"wsUrl": "ws://endpoint-2.example.com/ws",
    "httpUrl": "http://endpoint-2.example.com/",
		"sendOnly": false
	},
	{
		"name": "primary_3",
		"evmChainId": "137",
		"wsUrl": "wss://endpoint-3.example.com/ws",
    "httpUrl": "http://endpoint-3.example.com/",
		"sendOnly": false
	},
	{
		"name": "sendonly_1",
		"evmChainId": "137",
		"httpUrl": "http://endpoint-4.example.com/",
		"sendOnly": true
	},
  {
		"name": "sendonly_2",
		"evmChainId": "137",
		"httpUrl": "http://endpoint-5.example.com/",
		"sendOnly": true
	}
]
</tr></table> 

... (truncated)

Changelog

Sourced from @​chainlink/contracts's changelog.

[1.3.0] - 2022-04-18

Added

• Added support for Keeper registry v1.2 in keeper jobs
• Added disk rotating logs. Chainlink will now always log to disk at debug level. The default output directory for debug logs is Chainlink's root directory (ROOT_DIR) but can be configured by setting LOG_FILE_DIR. This makes it easier for node operators to report useful debugging information to Chainlink's team, since all the debug logs are conveniently located in one directory. Regular logging to STDOUT still works as before and respects the LOG_LEVEL env var. If you want to log in disk at a particular level, you can pipe STDOUT to disk. This automatic debug-logs-to-disk feature is enabled by default, and will remain enabled as long as the LOG_FILE_MAX_SIZE ENV var is set to a value greater than zero. The amount of disk space required for this feature to work can be calculated with the following formula: LOG_FILE_MAX_SIZE * (LOG_FILE_MAX_BACKUPS + 1). If your disk doesn't have enough disk space, the logging will pause and the application will log Errors until space is available again. New environment variables related to this feature:
  • LOG_FILE_MAX_SIZE (default: 5120mb) - this env var allows you to override the log file's max size (in megabytes) before file rotation.
  • LOG_FILE_MAX_AGE (default: 0) - if LOG_FILE_MAX_SIZE is set, this env var allows you to override the log file's max age (in days) before file rotation. Keeping this config with the default value means not to remove old log files.
  • LOG_FILE_MAX_BACKUPS (default: 1) - if LOG_FILE_MAX_SIZE is set, this env var allows you to override the max amount of old log files to retain. Keeping this config with the default value means to retain 1 old log file at most (though LOG_FILE_MAX_AGE may still cause them to get deleted). If this is set to 0, the node will retain all old log files instead.
• Added support for the force flag on chainlink blocks replay. If set to true, already consumed logs that would otherwise be skipped will be rebroadcasted.
• Added version compatibility check when using CLI to login to a remote node. flag bypass-version-check skips this check.
• Interrim solution to set multiple nodes/chains from ENV. This gives the ability to specify multiple RPCs that the Chainlink node will constantly monitor for health and sync status, detecting dead nodes and out of sync nodes, with automatic failover. This is a temporary stand-in until configuration is overhauled and will be removed in future in favor of a config file. Set as such: EVM_NODES='{...}' where the var is a JSON array containing the node specifications. This is not compatible with using any other way to specify node via env (e.g. ETH_URL, ETH_SECONDARY_URL, ETH_CHAIN_ID etc). WARNING: Setting this environment variable will COMPLETELY ERASE your evm_nodes table on every boot and repopulate from the given data, nullifying any runtime modifications. Make sure to carefully read the EVM performance configuration guide for best practices here.

For example:

export EVM_NODES='
[
	{
		"name": "primary_1",
		"evmChainId": "137",
		"wsUrl": "wss://endpoint-1.example.com/ws",
    "httpUrl": "http://endpoint-1.example.com/",
		"sendOnly": false
	},
	{
		"name": "primary_2",
		"evmChainId": "137",
		"wsUrl": "ws://endpoint-2.example.com/ws",
    "httpUrl": "http://endpoint-2.example.com/",
		"sendOnly": false
	},
	{
		"name": "primary_3",
		"evmChainId": "137",
		"wsUrl": "wss://endpoint-3.example.com/ws",
    "httpUrl": "http://endpoint-3.example.com/",
		"sendOnly": false
	},
	{
		"name": "sendonly_1",
		"evmChainId": "137",
		"httpUrl": "http://endpoint-4.example.com/",
		"sendOnly": true
	},
  {
		"name": "sendonly_2",
		"evmChainId": "137",
		"httpUrl": "http://endpoint-5.example.com/",
		"sendOnly": true
</tr></table> 

... (truncated)

Commits

• See full diff in compare view

Maintainer changes

This version was pushed to npm by secure.andrew, a new releaser for @​chainlink/contracts since your current version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)