Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem: there are duplicated hard coded informations in integration tests #233

Merged
merged 14 commits into from
Dec 6, 2021

Conversation

damoncro
Copy link
Contributor

@damoncro damoncro commented Nov 30, 2021

👮🏻👮🏻👮🏻 !!!! REFERENCE THE PROBLEM YOUR ARE SOLVING IN THE PR TITLE AND DESCRIBE YOUR SOLUTION HERE !!!! DO NOT FORGET !!!! 👮🏻👮🏻👮🏻

Close #10
This PR adds the following features:

  1. Add a .env file which consolidates all keys/mnemonic words/address etc. Scripts, python files, and all yamls can read the .env file to expand the keys/mnemonic words/address etc
  2. The yaml expansion job is done by pystarport.

Please merge crypto-com/pystarport#37 first.

PR Checklist:

  • Have you read the CONTRIBUTING.md?
  • Does your PR follow the C4 patch requirements?
  • Have you rebased your work on top of the latest master?
  • Have you checked your code compiles? (make)
  • Have you included tests for any non-trivial functionality?
  • Have you checked your code passes the unit tests? (make test)
  • Have you checked your code formatting is correct? (go fmt)
  • Have you checked your basic code style is fine? (golangci-lint run)
  • If you added any dependencies, have you checked they do not contain any known vulnerabilities? (go list -json -m all | nancy sleuth)
  • If your changes affect the client infrastructure, have you run the integration test?
  • If your changes affect public APIs, does your PR follow the C4 evolution of public contracts?
  • If your code changes public APIs, have you incremented the crate version numbers and documented your changes in the CHANGELOG.md?
  • If you are contributing for the first time, please read the agreement in CONTRIBUTING.md now and add a comment to this pull request stating that your PR is in accordance with the Developer's Certificate of Origin.

Thank you for your code, it's appreciated! :)

@damoncro damoncro requested a review from a team as a code owner November 30, 2021 03:28
@damoncro damoncro requested review from yihuang and thomas-nguy and removed request for a team November 30, 2021 03:28
@damoncro
Copy link
Contributor Author

damoncro commented Nov 30, 2021

I will fix the the bugs and lint asap. But it is ok to review first.

@codecov
Copy link

codecov bot commented Nov 30, 2021

Codecov Report

Merging #233 (3416c76) into main (3ea70c5) will increase coverage by 3.77%.
The diff coverage is 38.97%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main     #233      +/-   ##
==========================================
+ Coverage   21.51%   25.29%   +3.77%     
==========================================
  Files          27       34       +7     
  Lines        1729     2554     +825     
==========================================
+ Hits          372      646     +274     
- Misses       1324     1858     +534     
- Partials       33       50      +17     
Impacted Files Coverage Δ
app/prefix.go 0.00% <0.00%> (ø)
app/test_helpers.go 0.00% <0.00%> (ø)
x/cronos/keeper/gravity_hooks.go 0.00% <ø> (ø)
x/cronos/keeper/grpc_query.go 0.00% <ø> (ø)
x/cronos/keeper/ibc.go 83.20% <ø> (+5.01%) ⬆️
x/cronos/keeper/ibc_hooks.go 50.00% <ø> (-8.83%) ⬇️
x/cronos/keeper/keeper.go 64.89% <ø> (-29.45%) ⬇️
x/cronos/keeper/msg_server.go 4.76% <ø> (-1.69%) ⬇️
x/cronos/module.go 57.62% <ø> (-4.20%) ⬇️
x/cronos/proposal_handler.go 6.25% <ø> (ø)
... and 28 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c3a4283...3416c76. Read the comment docs.

@thomas-nguy
Copy link
Collaborator

there are still linter issues

@yihuang
Copy link
Collaborator

yihuang commented Nov 30, 2021

For the lint issues, you can configure black and isort as plugins in your editor, to auto-format it when save @chenyanming

@damoncro
Copy link
Contributor Author

@yihuang I just configured it. Should be ok now.

@yihuang yihuang self-requested a review November 30, 2021 06:47
Copy link
Collaborator

@yihuang yihuang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should support the expansion feature in pystarport directly, so people can still use pystarport serve --config scripts/devnet.yaml in cli directly.

@damoncro
Copy link
Contributor Author

ok, I'll change a little bit. By the way the PR here crypto-com/pystarport#37

@yihuang
Copy link
Collaborator

yihuang commented Nov 30, 2021

ok, I'll change a little bit. By the way the PR here crypto-com/pystarport#37

If that one is merged, we don't need to do the expansion here right?

@damoncro
Copy link
Contributor Author

damoncro commented Nov 30, 2021

@yihuang Yes, but .env can not work in our nix setting so far if it is relative path, crypto-com/pystarport#37 only works in cli usage, which I tested.

I still need to do some modifications on this PR.

@yihuang
Copy link
Collaborator

yihuang commented Nov 30, 2021

@yihuang Yes, but .env can not work in our nix setting so far if it is relative path, crypto-com/pystarport#37 only works in cli usage, which I tested.

why?

I still need to do some modifications on this PR.

@damoncro
Copy link
Contributor Author

damoncro commented Nov 30, 2021

the scripts.nix would copy the yaml files to nix store, if the .env is relative path, it is under /nix/store, of course, the .env is not there. But I can update default.nix and scripts.nix by not copying to nix store.

@yihuang
Copy link
Collaborator

yihuang commented Nov 30, 2021

the scripts.nix would copy the yaml files to nix store, if the .env is relative path, it is under /nix/store, of course, the .env is not there. But I can update default.nix and scripts.nix by not copying to nix store.

This can be solved by overriding the dotenv path with a parameter.

@damoncro
Copy link
Contributor Author

Good idea, I can also try parameterise it.

@damoncro
Copy link
Contributor Author

damoncro commented Nov 30, 2021

Now change the expansion code to pystarport. But The commit uses the test version of pystarport, need to finish and merge crypto-com/pystarport#37, before continuing.

@damoncro damoncro force-pushed the feature/expansion branch 2 times, most recently from 6c2a29e to 4d63980 Compare December 2, 2021 03:24
integration_tests/utils.py Outdated Show resolved Hide resolved
nix/default.nix Outdated
cronos-config = ../scripts/cronos-devnet.yaml;
hermes-config = ../scripts/hermes.toml;
geth-genesis = ../scripts/geth-genesis.json;
chainmain-config = builtins.toString ../scripts/chainmain-devnet.yaml;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the builtins.toString call?

Copy link
Contributor Author

@damoncro damoncro Dec 3, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is necessary to get the full path of the file (string), instead of copying to nix store. https://github.com/crypto-org-chain/cronos/blob/main/nix/scripts.nix#L15: if we use ../scripts/cronos-devnet.yaml and .env, then quote it with ${config.cronos-config} will copy to nix store.

Not copying to nix sotre has following benefits:

  1. Read .env with relative path just under the project script folder.
  2. In nix-shell environment, if we modify the cronos-devnet.yaml, we can call start-cronos directly without exiting the nix-shell and re-enter the nix-shell.

Copy link
Contributor Author

@damoncro damoncro Dec 3, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

start-cronos Before:

#!/nix/store/c9cxq1583a85bsq76q2rbnbiwwp7ygxr-bash-4.4-p23/bin/bash
# rely on environment to provide cronosd
export PATH=/nix/store/f347n055kzsyq30m41x481dpsq0zbip1-python3.8-pystarport-0.2.2/bin:$PATH
source /nix/store/ym2jzjqjmzf7azjkc8m9jd4vy0qjrx5p-dotenv
/nix/store/zhicf2wijlr36315xx1nxq5bhh6q90qs-start-cronos /nix/store/k0mfjv85j0sjbfjj6lisriwq3pkzcsqi-cronos-devnet.yaml $@

After:

#!/nix/store/c9cxq1583a85bsq76q2rbnbiwwp7ygxr-bash-4.4-p23/bin/bash
# rely on environment to provide cronosd
export PATH=/nix/store/fjm893gw3z5yd3f3vsabb5vw2my1dvd2-python3.8-pystarport-0.2.3/bin:$PATH
source /Users/damonchen/Documents/cronos/scripts/.env
/nix/store/zhicf2wijlr36315xx1nxq5bhh6q90qs-start-cronos /Users/damonchen/Documents/cronos/scripts/cronos-devnet.yaml $@



Copy link
Collaborator

@yihuang yihuang Dec 3, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then you don't get the reproducibility with these scripts.
In development, you can always run ./scripts/start-cronos config data explicitly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, treat it like a fixed binary. Let me think a more thoughtful idea.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But seems no documents here, user would not know start-cronos exists. The binary is not useful because it only works in nix-shell. Even me, I don't use it at all.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Of course, it is important in integration test. Just not that useful for users, assuming they do not have nix installed.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

start-cronos and start-geth are only used to start cronos and geth devnets with the identical environment, to run cronos devnet with custom config, one can always use pystarport directly, the scripts/start-cronos is only a thin wrapper over that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two TODOs here:

  1. Make all ShellScriptBin reproducible. And add documents if possible.
  2. Improve all scripts. E.g. So that user knows they can use dotenv option as well.

Copy link
Collaborator

@yihuang yihuang Dec 6, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These scripts are not intended to be used by user, so just keep it simple here, only start-geth is useful for normal user, the other scripts are thin wrappers of pystarport.
We can even remove start-chainmain and start-cronos, and simply use pystarport directly.

nix/sources.json Outdated Show resolved Hide resolved
scripts/.env Show resolved Hide resolved
and remove deepdiff dependency.
It is more general and work with full path as well
This makes these two script-bins defined in `scripts.nix` always use the
same yaml and dotenv file, for metting the "re-producibility"
requirement during one/same `nix-shell` environment.

These script-bins are wrappers of pystarport with fixed yaml and dotenv.

If you want to create the cronos/chainmain instance with different
configurations, you should avoid using the script-bins. Please run the
scripts directly, or use `pystarport` step by step.

Besides, if you change the yaml or dotenv, you need to exit and
re-enter the nix-shell. So that the modified yaml or dotenv are copied
to nix store, and their paths can be rewritten into these two
script-bins.
@yihuang yihuang merged commit af16f2a into crypto-org-chain:main Dec 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Problem: there are duplicated hard coded informations in integration tests
3 participants