feat(txtar): txtar file options & formating

[gfanton]

I initially aimed to resolve timeout issue caused by a potential process leak when a node was not ready, which led to test failures. The process could persist because it was not terminated.

I've ended adding a way to customize the test runtime on a file-by-file basis using flag options with # txtar:opts <flags> at the beginning of the file.

-no-fmt
     Disable formatting of Gno files in this test file. Use this to preserve original formatting.

-no-parallel
     Disable parallel execution for this test file. This is handled natively using t.Parallel.

-skip
     Skip this test file entirely.

-timeout <duration>
     Set a custom timeout for this test file (e.g., -timeout 90s).

e.g with gc.txtar file:

You can find more infos in doc.go within integration folder.

This feature also enables an easy and convenient way to integrate more options in the future at either the file or test level.

Note

• -no-parallel flag override previous implementation by doing it natively using t.Parallel instead of mutex locking.
• -timeout can be set either at file flags level (global file timeout), or at node level using gnoland start -timeout=x

Formatting

I also added a way to format gno files within txtar. You can use it with go test -ts-fmt (files using -no-fmt option will not be formated). This formatting is not yet enforced in the CI, as it can be somewhat inconvenient to run. It requires a test to be fully complete and the package to be loaded in memory to resolve and format the file. While it should be possible to enforce this, I will add it to the CI later.

this PR include formatting on some txtar files

[Gno2D2]

🛠 PR Checks Summary

All Automated Checks passed. ✅

Manual Checks (for Reviewers):

• IGNORE the bot requirements for this PR (force green CI check)

Read More

🤖 This bot helps streamline PR reviews by verifying automated checks and providing guidance for contributors and reviewers.

✅ Automated Checks (for Contributors):

🟢 Maintainers must be able to edit this pull request (more info)

☑️ Contributor Actions:

1. Fix any issues flagged by automated checks.
2. Follow the Contributor Checklist to ensure your PR is ready for review.
   • Add new tests, or document why they are unnecessary.
   • Provide clear examples/screenshots, if necessary.
   • Update documentation, if required.
   • Ensure no breaking changes, or include BREAKING CHANGE notes.
   • Link related issues/PRs, where applicable.

☑️ Reviewer Actions:

1. Complete manual checks for the PR, including the guidelines and additional checks if applicable.

📚 Resources:

• Report a bug with the bot.
• View the bot’s configuration file.

Debug

Automated Checks

Maintainers must be able to edit this pull request (more info)

If

🟢 Condition met
└── 🟢 And
    ├── 🟢 The base branch matches this pattern: ^master$
    └── 🟢 The pull request was created from a fork (head branch repo: gfanton/gno)

Then

🟢 Requirement satisfied
└── 🟢 Maintainer can modify this pull request

Manual Checks

**IGNORE** the bot requirements for this PR (force green CI check)

If

🟢 Condition met
└── 🟢 On every pull request

Can be checked by

• Any user with comment edit permission

[codecov]

Codecov Report

❌ Patch coverage is 49.49495% with 100 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
gno.land/pkg/integration/testscript_gnoland.go	32.07%	68 Missing and 4 partials ⚠️
gnovm/pkg/gnofmt/package.go	0.00%	13 Missing ⚠️
gno.land/pkg/integration/pkgloader.go	0.00%	10 Missing ⚠️
gno.land/pkg/integration/utils.go	92.98%	3 Missing and 1 partial ⚠️
gnovm/pkg/gnofmt/resolver_mock.go	91.66%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[moul]

Can we use direct commands instead of comments, perhaps something like "setop opt=foo"?

[gfanton]

Those options are test-level instructions that impact this integration test only, and they need to be interpreted and parsed ahead of time, before running and setting up GnolandTestscript. The only way to achieve what you are saying would be to create a dummy command setop within the GnolandTestscript and parse this instruction beforehand. Ideally, I don't want GnolandTestscript to be aware of this instruction as it is not the one that is actually using it. While it would be somehow doable, im a bit against it. those instruction should be rare.

That said, it's not the case for all the instructions; it only matters for -no-parallel and -skip, as they are the ones using native go testing features (t.Parallel & t.Skip). The rest could technically be moved as instructions. that mean we could use no-fmt and timeout as direct command for e.g

[thehowl]

I'm also more in favor of putting the options inside of a command; this would have to be parsed beforehand, as you mentioned @gfanton, but I think it's better if the "directive" is considered as part of the code rather than being a special comment.

[gfanton]

Alright, you guys win, I will implement the setopts command