Merge Additional Logs into new v0.11.6 release of Paloma. (#663)

* chore: release infra (#629) * updates * updates * updates (#647) * Update README for v0.11.5 (#651) * convert get current snapshot info log into debug log (#656) * convert get current snapshot info log into debug log * info to debug * add logs (#659) Co-authored-by: Aleksandr Bezobchuk <[email protected]> Co-authored-by: webelf101 <[email protected]>
palomachain · Jan 19, 2023 · 6a6c928 · 6a6c928
1 parent 141b17e
commit 6a6c928
Show file tree

Hide file tree

Showing 8 changed files with 119 additions and 14 deletions.
diff --git a/.mergify.yml b/.mergify.yml
@@ -0,0 +1,26 @@
+queue_rules:
+  - name: default
+    conditions:
+      - "#approved-reviews-by>1"
+
+pull_request_rules:
+  - name: "Auto-merge to master branch with label 'A:automerge' and branch protection passing"
+    conditions:
+      - "#approved-reviews-by>1"
+      - base=master
+      - label=A:automerge
+    actions:
+      queue:
+        name: default
+        method: squash
+        commit_message_template: |
+          {{ title }} (#{{ number }})
+          {{ body }}
+  - name: Backport patches to v0.11.x branch
+    conditions:
+      - base=master
+      - label=backport/0.11.x
+    actions:
+      backport:
+        branches:
+          - release/v0.11.x
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -0,0 +1,35 @@
+<!--
+Guiding Principles:
+
+Changelogs are for humans, not machines.
+There should be an entry for every single version.
+The same types of changes should be grouped.
+Versions and sections should be linkable.
+The latest version comes first.
+The release date of each version is displayed.
+Mention whether you follow Semantic Versioning.
+
+Usage:
+
+Change log entries are to be added to the Unreleased section under the
+appropriate stanza (see below). Each entry should ideally include a tag and
+the Github issue reference in the following format:
+
+* (<tag>) [#<PR-number](<link-to-PR>) <message>
+
+Types of changes (Stanzas):
+
+"Features" for new features.
+"Improvements" for changes in existing functionality.
+"Deprecated" for soon-to-be removed features.
+"Bug Fixes" for any bug fixes.
+"Client Breaking" for breaking Protobuf, gRPC and REST routes used by end-users.
+"CLI Breaking" for breaking CLI commands.
+"API Breaking" for breaking exported APIs used by developers building on SDK.
+"State Machine Breaking" for any changes that result in a different AppState given same genesisState and txList.
+Ref: https://keepachangelog.com/en/1.0.0/
+-->
+
+# Changelog
+
+## [Unreleased]
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -1,6 +1,6 @@
 # Contributing
 
-Thank you for considering making contributions to Paloma. We welcome all messenger birds! 
+Thank you for considering making contributions to Paloma. We welcome all messenger birds!
 
 Contributing to this repo can mean many things such as participating in
 discussions or proposing new features, improvements or bug fixes. To ensure a
@@ -41,7 +41,7 @@ contributing has been established:
 
 We follow the Cosmos SDK [Coding Guidelines](https://github.com/cosmos/cosmos-sdk/blob/main/CODING_GUIDELINES.md). Specifically:
 
-- API & Design SHOULD be proposed and reviewed before the main implementaion.
+- API & Design SHOULD be proposed and reviewed before the main implementation.
 - Minimize code duplication
 - Define [Acceptance tests](https://github.com/cosmos/cosmos-sdk/blob/main/CODING_GUIDELINES.md#acceptance-tests) or while implementing new features.
   - Prefer use of acceptance test framework, like [gocuke](https://github.com/regen-network/gocuke/)
@@ -68,17 +68,16 @@ model and utilizes [semantic versioning](https://semver.org/).
 
 ### PR Targeting
 
-Ensure that you base and target your PR against the `main` branch.
+Ensure that you base and target your PR against the `master` branch.
 
-All feature additions should be targeted against `main`. Bug fixes for an
+All feature additions should be targeted against `master`. Bug fixes for an
 outstanding release candidate should be targeted against the release candidate
 branch.
 
 ### PR & Merge Procedure
 
-- Ensure the PR branch is rebased on `main`.
+- Ensure the PR branch is rebased on `master`.
 - Ensure you provided unit tests and integration tests.
-- Run `make test-unit test-e2e` to ensure that all tests pass.
 - Merge the PR!
 
 ## Release procedure
@@ -89,6 +88,42 @@ We follow semver (from v3.0.0):
 - minor version update (eg 2.1.x -> 2.2.0) has no API nor state machine breaking changes. It can provide new functionality or bug fixes.
 - patch version update (eg 2.1.0 -> 2.1.1) has no API nor state machine breaking changes nor new features. It only contains hot fixes.
 
+Note, when the major version is 0, we adopt a 0-based versioning scheme:
+
+- major version update (eg 0.12.x -> 0.13.x) has API breaking changes or signals major feature update
+- minor version update (eg 0.12.1 -> 0.12.2) has no API nor state machine breaking changes. It can provide new functionality or bug fixes.
+
 ### Major Release Procedure
 
-All major changes related to major version update are first released for testnet. We use `-betaX` (eg `2.0.0-beta1`, `2.0.0-beta2` ...) releases for testnet. Once the code is stabilized we create a release candidate (eg `2.0.0-rc1`). If no issues are found the latest release candidate become the major release.
+All major changes related to major version update are first released for testnet.
+We use `-betaX` (eg `2.0.0-beta1`, `2.0.0-beta2` ...) releases for testnet.
+Once the code is stabilized we create a release candidate (eg `2.0.0-rc1`).
+If no issues are found the latest release candidate become the major release.
+
+When a major release is ready to be made, perform the following:
+
+1. Create a `release/vX.*.*` release.
+branch off of the desired commit on `master`, e.g. `release/v0.12.x` or `release/v1.x.x`.
+2. Create a `RELEASE_NOTES.md` template.
+3. Ensure correct branch protection rules are enabled. This can be done generally
+   using a regex such as `release/v*`.
+4. Create a branch off of the release branch that prepares the `RELEASE_NOTES.md`
+   based on the changelog.
+5. Review and merge the release notes PR.
+6. Cut a release off of the release branch! Note, goreleaser should automatically
+   create the release artifacts once the tag is pushed.
+7. Ensure changelog entries are updated on `master`, i.e. have the release date,
+   version, and link to the release.
+
+### Minor Release Procedure
+
+All changes should be merged into `master`, unless a change is needed against a
+specific release only.
+
+When a change is needed in a current release, add the appropriate `backport/*` label
+to the PR and Mergify will automatically create a backport PR against the release
+branch. If a PR is already merged, you can comment on the PR for Mergify to create
+the backport PR via `@Mergifyio backport release/vX.*.*` (use the relevant release branch name).
+
+When you are ready to cut a point release, perform steps 4-7 from the Major
+Release Procedure.
diff --git a/README.md b/README.md
@@ -60,7 +60,7 @@ See [Release procedure](CONTRIBUTING.md#release-procedure) for more information
 To get the latest `palomad` binary:
 
 ```shell
-wget -O - https://github.com/palomachain/paloma/releases/download/v0.11.4/paloma_Linux_x86_64.tar.gz  | \
+wget -O - https://github.com/palomachain/paloma/releases/download/v0.11.5/paloma_Linux_x86_64.tar.gz  | \
   sudo tar -C /usr/local/bin -xvzf - palomad
 sudo chmod +x /usr/local/bin/palomad
 # Required until we figure out cgo
@@ -73,10 +73,10 @@ If you're upgrading to the most recent version, you will need to stop `palomad`
 
 **ALERT: You will need to update your pigeon config.yaml file to reference this new chain-ID!**
 
-1. Stop your paloma version and get 0.11.3
+1. Stop your paloma version and get 0.11.5
 ```
 service palomad stop
-wget -O - https://github.com/palomachain/paloma/releases/download/v0.11.4/paloma_Linux_x86_64.tar.gz | \
+wget -O - https://github.com/palomachain/paloma/releases/download/v0.11.5/paloma_Linux_x86_64.tar.gz | \
   tar -C /usr/local/bin -xvzf - palomad
 ```
 
@@ -118,8 +118,8 @@ palomad init "$MONIKER"
 Copy the configs of the testnet we wish to connect to
 
 ```shell
-wget -O ~/.paloma/config/genesis.json https://raw.githubusercontent.com/palomachain/testnet/master/paloma-testnet-12/genesis.json
-wget -O ~/.paloma/config/addrbook.json https://raw.githubusercontent.com/palomachain/testnet/master/paloma-testnet-12/addrbook.json
+wget -O ~/.paloma/config/genesis.json https://raw.githubusercontent.com/palomachain/testnet/master/paloma-testnet-13/genesis.json
+wget -O ~/.paloma/config/addrbook.json https://raw.githubusercontent.com/palomachain/testnet/master/paloma-testnet-13/addrbook.json
 ```
 
 Next you can generate a new set of keys to the new machine, or reuse an existing key.

diff --git a/x/evm/keeper/attest.go b/x/evm/keeper/attest.go
@@ -59,6 +59,7 @@ func (c *consensusPower) consensus() bool {
 }
 
 func (k Keeper) attestRouter(ctx sdk.Context, q consensus.Queuer, msg consensustypes.QueuedSignedMessageI) (retErr error) {
+	k.Logger(ctx).Debug("attest-router", "msg-id", msg.GetId(), "msg-nonce", msg.Nonce())
 	if len(msg.GetEvidence()) == 0 {
 		return nil
 	}

diff --git a/x/evm/keeper/attest_validator_balances.go b/x/evm/keeper/attest_validator_balances.go
@@ -13,6 +13,7 @@ import (
 )
 
 func (k Keeper) attestValidatorBalances(ctx sdk.Context, q consensus.Queuer, msg consensustypes.QueuedSignedMessageI) (retErr error) {
+	k.Logger(ctx).Debug("attest-validator-balances", "msg-id", msg.GetId(), "msg-nonce", msg.Nonce())
 	if len(msg.GetEvidence()) == 0 {
 		return nil
 	}

diff --git a/x/evm/keeper/keeper.go b/x/evm/keeper/keeper.go
@@ -747,6 +747,13 @@ func (k Keeper) CheckExternalBalancesForChain(ctx sdk.Context, chainReferenceID
 			if ext.GetChainReferenceID() == chainReferenceID && ext.GetChainType() == "evm" {
 				msg.ValAddresses = append(msg.ValAddresses, val.GetAddress())
 				msg.HexAddresses = append(msg.HexAddresses, ext.GetAddress())
+				k.Logger(ctx).Debug("check-external-balances-for-chain",
+					"chain-reference-id", chainReferenceID,
+					"msg-val-address", val.GetAddress(),
+					"msg-hex-address", ext.GetAddress(),
+					"val-share-count", val.ShareCount,
+					"ext-chain-balance", ext.Balance,
+				)
 			}
 		}
 	}

diff --git a/x/valset/keeper/keeper.go b/x/valset/keeper/keeper.go
@@ -365,7 +365,7 @@ func (k Keeper) GetCurrentSnapshot(ctx sdk.Context) (*types.Snapshot, error) {
 	snapStore := k.snapshotStore(ctx)
 	lastID := k.ider.GetLastID(ctx, snapshotIDKey)
 	snapshot, err := keeperutil.Load[*types.Snapshot](snapStore, k.cdc, keeperutil.Uint64ToByte(lastID))
-	k.Logger(ctx).Info("get current snapshot", "last-id", lastID, "snapshot-validator-size", len(snapshot.Validators))
+	k.Logger(ctx).Debug("get current snapshot", "last-id", lastID, "snapshot-validator-size", len(snapshot.Validators))
 	if errors.Is(err, keeperutil.ErrNotFound) {
 		return nil, nil
 	}
@@ -508,6 +508,6 @@ func (k Keeper) _externalChainInfoStore(ctx sdk.Context) sdk.KVStore {
 }
 
 func (k Keeper) snapshotStore(ctx sdk.Context) sdk.KVStore {
-	k.Logger(ctx).Info("snapshot store", "store-key-name", k.storeKey.Name(), "store-key-string", k.storeKey.String())
+	k.Logger(ctx).Debug("snapshot store", "store-key-name", k.storeKey.Name(), "store-key-string", k.storeKey.String())
 	return prefix.NewStore(ctx.KVStore(k.storeKey), []byte("snapshot"))
 }