Feat/local devnet

[omidasadpour]

/close #8
/close #14
This PR will deploy rollups nodes along with anvil local node.

[omidasadpour]

Hardhat CI Test: https://github.com/cartesi/helm-charts/actions/runs/5531102174/jobs/10091342487?pr=9

Anvil CI Test: https://github.com/cartesi/helm-charts/actions/runs/5531395687/jobs/10092031860

[endersonmaia]

Let's make it simple and keep only anvil.

[endersonmaia]

asked for some changes on my last review comments

[endersonmaia]

squash the fixups

[omidasadpour]

/close #14 We can use the command below to test the graphql-server connectivity after install the release.

helm test $RELEASE_NAME

In CI, the chart-testing section will test the chart automatically.

[endersonmaia]

The only thing missing is the labels: empty line, I've left a suggestion on how to solve it.

[omidasadpour]

The only thing missing is the labels: empty line, I've left a suggestion on how to solve it.

Fixed the problem !

[endersonmaia]

So that this PR entres the next release, you should target the branch feature/rollups-1.0.0.

There, I already split the deployment.yaml in 3 different files.

[omidasadpour]

So that this PR entres the next release, you should target the branch feature/rollups-1.0.0.

There, I already split the deployment.yaml in 3 different files.

This PR is older than the feature/rollups-1.0.0. and is ready to merge. also the feature/rollups-1.0.0 PR is still in Draft.

I think it would be better if we close this PR and then sync the feature/rollups-1.0.0 with the latest changes of the release/1.0.0 branch .

What do U think ?

[endersonmaia]

So that this PR entres the next release, you should target the branch feature/rollups-1.0.0.
There, I already split the deployment.yaml in 3 different files.

This PR is older than the feature/rollups-1.0.0. and is ready to merge. also the feature/rollups-1.0.0 PR is still in Draft.

I think it would be better if we close this PR and then sync the feature/rollups-1.0.0 with the latest changes of the release/1.0.0 branch .

What do U think ?

Whatever is easy for you.

We decided that devnet should go into release 1.0.0, even if it's still a draft, we'll only release 1.0.0 when everything is working.

[endersonmaia]

Need to squash the fixups and remote DELETE commits.

The version/revision will be tackled on a release commit, let's keep the commit into next branch generic and without version information

Maybe this next branch strategy won't work here because of the way ct makes releases and checks for changes between branches, IDK.

I'll assume that we can change the next history before a final merge into main.

[endersonmaia]

the last commit comment is DOC: when it should be doc:, lowercase.

[endersonmaia]

I think we could reduce the depth for the validator.localnode.anvil removing the .anvil element.

validator.localnode should be enough, and the use of anvil would be an "implementation detail¨, so that if the user changes valiator.localnode. parameters, they can change to hardhat or whatever, for ex., and adapt where is needed.

[omidasadpour]

I think we could reduce the depth for the validator.localnode.anvil removing the .anvil element.

validator.localnode should be enough, and the use of anvil would be an "implementation detail¨, so that if the user changes valiator.localnode. parameters, they can change to hardhat or whatever, for ex., and adapt where is needed.

I think it's not a good solution. because we have lots of dependencies like initcontainers based on anvil.

So, we may have other localnodes in future like hardhat.

I think we should not change the structure.