Skip to content
  1. Nov 01, 2024
  2. Oct 24, 2024
  3. Oct 16, 2024
  4. Oct 03, 2024
    • Özgün Özerk's avatar
      Zombienet Improve DevX with new methods (#261) · 3460ec1c
      Özgün Özerk authored
      Revamped version of #252, didn't overwrite that PR in case you guys want
      to compare both solutions.
      
      Fixes #251 
      
      
      TL;DR -> here is the suggestion:
      ```rust
      let network_config = NetworkConfigBuilder::with_nodes_and_chain(
          vec!["alice".to_string(), "bob".to_string()],
          "rococo-local",
      )
      .with_collators_and_parachain_id(vec!["collator1".to_string(), "collator2".to_string()], 100)
      .build()
      .unwrap();
      ```
      
      I found an even better way than creating a wrapper. Here is the summary:
      
      - I want to protect the safety measures provided by the original crate
      as we discussed.
      - At the same time, I don't want to opt-out of the high-degree of
      configurability that `configuration` crate offers. Even though the aim
      is to grant better DevX to the community, it should still preserve the
      configuration options.
      - “advanced users can still use the `configuration` crate if they wanted
      to” is not a good argument imo. Here is the reason:
      - although there are many common settings amongst the projects in the
      ecosystem, probably most of the projects only tinkers with a specific
      setting w.r.t their needs, and this specific setting is most likely
      changing across projects. So, if we do not expose the tinkering options
      to people with this wrapper approach, most of the projects won’t use
      this wrapper. Then what is the point?
      - The aim should be providing the default options with a better DevX,
      whilst still providing a way to configure niche details somehow within
      the same API.
      - As first trial, I completed simple to use wrapper builders with the
      default settings. However, to expose the niche configurations, I had to
      copy-paste nearly every other function/method in the `configuration`
      crate.
      - And also, in order to comply with the `configuration` crate’s type
      state pattern, I had to export nearly all the states from
      `configuration` crate for the builder types in the `lib.rs`. The whole
      thing was quickly becoming ugly.
      - The difference between my wrapper and the `configuration` crate was,
      basically the extra methods that granted better DevX (for initializing
      the structs with default settings).
      - So I thought, instead of creating a new wrapper with tremendous amount
      of duplications, I can simply put these new methods into the
      `configuration` crate itself!
      
      Notes:
      
      - there are 2 new methods: (edited after last commit)
          - `with_nodes_and_chain`
          - `with_collators_and_parachain_id`
      - I also expanded the tests for these new methods.
      - I want to signal to the developers that these new methods are easier
      and faster to use compared to their equivalents, since they are
      utilizing the default settings, and should be much less intimidating to
      newcomers
      - So, I tried to name the methods accordingly, but they turned out to be
      a bit long. Don't know whether we can do better, I'm open to all
      suggestions.
      
      Hope it makes sense!
      3460ec1c
    • Javier Viola's avatar
      add validation to node name, can't be empty (#266) · bd51865f
      Javier Viola authored
      Add: 
        - Validate `node_name`, can't be empty
      
      cc: @ozgunozerk
      bd51865f
  5. Sep 24, 2024
  6. Sep 22, 2024
  7. Sep 20, 2024
  8. Sep 12, 2024
  9. Aug 28, 2024
    • Javier Viola's avatar
      support single collator config in `toml` (#253) · 9f8845dc
      Javier Viola authored
      `v1` version support define a parachain with a single collator using
      `[parachain.collator]` (note this is a map and not a sequence). But in
      the `sdk` we drop support in favor of always use a vec<NodeConfig>. This
      pr allow to use the old toml definition __only__ with the load_from_toml
      method.
      
      cc:  @AlexD10S
      9f8845dc
    • Özgün Özerk's avatar
      reuse pjs code execution code (#243) · f8ed4994
      Özgün Özerk authored
      
      
      This is nothing big  :) 
      
      The code execution logic is already present under `pjs` function, yet it
      is duplicated for `pjs_file` function.
      
      This change re-uses the existing code, so that you won't have to change
      it twice in the future.
      
      Co-authored-by: default avatarJavier Viola <[email protected]>
      f8ed4994
  10. Aug 20, 2024
  11. Aug 15, 2024
  12. Aug 13, 2024
    • Frank Bell's avatar
      fix(chain-spec): adjust hrmp channels json structure (#244) · b1aac0ea
      Frank Bell authored
      When testing `zombienet-sdk` with cross-chain calls with Asset Hub, we
      found that the hrmp channels passed to the chainspec caused the
      following issue:
      
      `Error: "Invalid JSON blob: invalid type: map, expected a tuple of size
      4 at line 1 column 2794"`
      
      This is because the values of `HrmpChannelConfig` serialise to a map
      instead of a tuple, as expected by
      https://github.com/paritytech/polkadot-sdk/blob/fc906d5d0fb7796ef54ba670101cf37b0aad6794/polkadot/runtime/parachains/src/hrmp.rs#L492.
      Tests were updated accordingly to facilitate this fix.
      
      Additional commits were also added to enable some of Asset Hub on
      Polkadot functionality observed in the classic Zombienet repo, so that
      we are able to launch a local Polkadot network with Asset Hub should
      anyone require. Example configuration files can be found at the bottom
      of https://github.com/r0gue-io/pop-cli/pull/278/files for anyone
      interested, although that PR is still a work in progress and dependent
      on this one being accepted.
      
      PS - I added tests where I could, but additional tests might require
      some minor refactoring to make it easier to test only the logic that is
      changed by this PR, which I am not sure what the appetite is? An example
      would be refactoring the file name generation in `keystore.rs` into its
      own function to more easily test the outputs without the `scoped_fs`.
      b1aac0ea
  13. Jul 20, 2024
  14. Jul 16, 2024
  15. Jun 22, 2024
  16. Jun 21, 2024
  17. Jun 14, 2024
  18. Jun 13, 2024
  19. Jun 10, 2024
  20. Jun 09, 2024
  21. Jun 08, 2024
  22. Jun 05, 2024
  23. Jun 04, 2024
  24. Jun 03, 2024