Find an alternative to distribute Neo-VM test files

[lock9]

Summary or problem description
The Neo VM project is being migrated to the Neo repository. Inside the Neo VM project, there are test specifications in JSON:
https://github.com/neo-project/neo-vm/tree/master/tests/Neo.VM.Tests/Tests

Other groups, like NSPCC, are using these tests. If we migrate the neo-vm repository, they will need to download the entire mono repo to access it.

Do you have any solution you want to propose?
We should distribute these tests using some other form. I'm against creating a new repository for it. I propose distributing these files as part of the release (compress the folder and add it as a release artifact).

Neo Version

• Neo 3

Where in the software does this update apply?

• VM

[Jim8y]

How about make it a repo (i know you want to avoid), and add it to the core as a submodule.

[cschuchardt88]

@Liaojinghui @lock9 No need just add ignore in the *.csproj and in the workflow change the current directory to the that project for the test.

[lock9]

How about make it a repo (i know you want to avoid), and add it to the core as a submodule.

Why a new repository? I don't think we need a new repository to distribute the tests. It seems too much.

@Liaojinghui @lock9 No need just add ignore in the *.csproj and in the workflow change the current directory to the that project for the test.

They have the Neo-VM repository as a submodule. I'm not sure if this will make any difference

[roman-khimov]

Release is a release, but when some new ones are added (which doesn't happen often, but still) we want the latest and greatest immediately. Other options:

• Have them in neo-project/neo, add it as a submodule to NeoGo. I'm worried @AnnaShaleva will beat me for doing this.
• Have them in neo-project/neo, download in some test workflow. Makes NeoGo VM harder to test.
• Move to another repo and have fun synchronizing with neo-project/neo. These JSON were updated just four times since Nov 10 2021 though.

Likely, I shouldn't be deciding on this one, I'm just too biased to solutions that'd be easier to integrate into third-party repos.

[lock9]

Release is a release, but when some new ones are added (which doesn't happen often, but still) we want the latest and greatest immediately. Other options:

• Have them in neo-project/neo, add it as a submodule to NeoGo. I'm worried @AnnaShaleva will beat me for doing this.
• Have them in neo-project/neo, download in some test workflow. Makes NeoGo VM harder to test.
• Move to another repo and have fun synchronizing with neo-project/neo. These JSON were updated just four times since Nov 10 2021 though.

Likely, I shouldn't be deciding on this one, I'm just too biased to solutions that'd be easier to integrate into third-party repos.

Could you define 'latest'? Is it when it has been merged? Or are you making the changes yourself?

[Jim8y]

Could you define 'latest'? Is it when it has been merged? Or are you making the changes yourself?

I think he means the new merges that are not released yet. Otherwise other projects have to wait until the release to catch up.

[roman-khimov]

We're taking changes from the repo when we need to, like in nspcc-dev/neo-go@3e6ce3c

And it's taken as is. And yes, waiting for the release is not a viable option, NeoGo usually has a compatible release in a day or two from C# release.

When we have something to push into this set of tests, we do things like neo-project/neo-vm#453

[roman-khimov]

I think we could have a copy in NeoGo and some script to sync. We have to do something when we sync anyway and a submodule update doesn't differ much from script invocation. Regular test runs will always have this data while the original set would stay here. @AnnaShaleva?

[lock9]

What if we make a .zip file with the test folder after each build? And add the zip to the repository.

Pros:

• No need for a new repository
• You can change the code locally and have access to the latest changes
• It's possible to download the file directly using a link

Cons:

• It will require changes on the Neo Go side
• It will require some changes on Neo side
• I would recommend distributing the file hash with the zip file so we know when there are changes
• There will be a new file with 'repeated content', However I don't think this is going to have an impact.
• If we always rebuild the zip, the build process will become slower.

[AnnaShaleva]

What if we make a .zip file with the test folder after each build?

I don't think we need to make the build process more complicated. Just let the tests be in the neo-project/neo repository, as they are now. I'm pretty sure that NeoGo is able to handle downloading tests from the monorepository with the help of a tiny script, whereas NeoVM doesn't need to change anything to run these tests. And AFAIK, no one except NeoVM and NeoGo needs NeoVM tests.

Have them in neo-project/neo, add it as a submodule to NeoGo.

We don't need the whole monorepo as a submodule.

I think we could have a copy in NeoGo and some script to sync. We have to do something when we sync anyway and a submodule update doesn't differ much from script invocation.

Exactly, I'll create a prototype within the scope of nspcc-dev/neo-go#3204.

To conclude, I'd suggest not to change things on the neo-project/neo side and close this issue as "not planned".