Can the workflow try to create CalcJobs with additional attributes to be tested?

[giovannipizzi]

For instance there is a comment (probably non-critical) on custom_environment_variables for CalcJobs. Should we try to generate CalcJobs with all these attributes that change? (Similarly for other things that have changed).

[CasperWA]

This is a great idea. And was the initial thought as well. I think, since we did so many changes from export version v0.3 to v0.4, it was instead concluded to do a "simple" workflow that tries to provide good tests for as many of the migrations as possible, but also saying "if we got the tougher migrations correct, and have some of the simpler ones, then they should all be fine". This is of course not a completionist mindset, but it makes it easier to do the workflow.
In general, I think we aimed for something with TrajectoryData (since this is a big change), a complex provenance graph (to test the migration logic of this properly) and then see what else falls out. The rest of the migrations are usually very general to all Nodes or similar.

[CasperWA]

For instance there is a comment (probably non-critical) on custom_environment_variables for CalcJobs. Should we try to generate CalcJobs with all these attributes that change? (Similarly for other things that have changed).

I may have misunderstood this. However, my previous answer does cover some of the true answer, i.e., we aimed to cover as wide a range of changes as possible, while keeping the general workflow the same. This means that some specific migrations are not directly tested, only indirectly through the success of the import and success of other "surrounding" migrations. Although we have tried, as previously stated, to directly test the major changes/migrations.

However, if there is a need to create multiple different attributes for testing migrations between a single incremental version, there is no reason why additional, specialized, files could not be produced to reflect this/these tests.

In the end, the goal is to make sure we don't do mistakes when migrating archives, and this repo's function is to store archives that can be used to test this. So if more are needed to test a single set of migrations, then it should be completely fine.