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

[FR] - cardano-testnet: DevX improvements #5848

Open
klntsky opened this issue May 20, 2024 · 5 comments
Open

[FR] - cardano-testnet: DevX improvements #5848

klntsky opened this issue May 20, 2024 · 5 comments
Labels
Stale type: enhancement An improvement on the existing functionality

Comments

@klntsky
Copy link

klntsky commented May 20, 2024

External

Area
Other

Describe the feature you'd like

We're considering replacing Plutip with cardano-testnet, and we'd like to see some changes upstream for our convenience.

  1. We'd like to make running the test suite optional, configurable via a CLI option. We really need faster startup times.
  2. We'd like to see more structured output (e.g. JSON) so that we can parse the TMP dir to get the node socket path, etc.

If we implement these changes in a PR, would it be considered for acceptance?

@klntsky klntsky added the type: enhancement An improvement on the existing functionality label May 20, 2024
@smelc
Copy link
Contributor

smelc commented May 21, 2024

cc @Jimbo4350 @carbolymer

@carbolymer
Copy link
Contributor

We'd like to make running the test suite optional, configurable via a CLI option. We really need faster startup times.

Actually, there are no tests executed when you're starting cardano-testnet using the cardano-testnet executable. It may appear so, because we're leveraging hedgehog's PropertyT when setting up the testnet nodes. So we're kind of abusing it to print debugging information by failing the test suite. All it does is starting the nodes and doing the healthcheck, so I think you won't get more speedup than it is right now (speaking about version in master).

We'd like to see more structured output (e.g. JSON) so that we can parse the TMP dir to get the node socket path, etc.

Definitely, if you feel that you can make the output both human readable and machine readable (by some toggle?) we'd be up for it.

If we implement these changes in a PR, would it be considered for acceptance?

Sure, if it won't be disruptive too much. It would be preferable if you could submit your changes in few smaller PRs.

@klntsky
Copy link
Author

klntsky commented May 22, 2024

@carbolymer Thank you!

I have one more question: would it be possible for it to start instantly in the latest era, skipping the initial era transitions?

@carbolymer
Copy link
Contributor

That's supported already. In some of the test cases we're starting in Conway already, for example in here:

Copy link

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

@github-actions github-actions bot added the Stale label Jun 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Stale type: enhancement An improvement on the existing functionality
Projects
None yet
Development

No branches or pull requests

3 participants