integration test: move config.json to the code.

[utam0k]

I think the bundle.tar.gz contains config.json, which makes it difficult to understand, so I will generate it in code.

[YJDoc2]

Hey @utam0k , what is the specific aim of this PR? the reason I am asking is that except for lifecycle tests and create tests, which does not require any specific config, all other tests generate their own config and that is copied to the bundle.

If I'm not mistaken, this PR will essentially create the same basic config file, and save it to the bundle file, only to be overwritten by most of the tests anyways. In that case rather than having an overhead of creating a config object, serializing it and saving it, isn't the current way which uses the default file from the gzip better?

[utam0k]

Hey @utam0k , what is the specific aim of this PR? the reason I am asking is that except for lifecycle tests and create tests, which does not require any specific config, all other tests generate their own config and that is copied to the bundle.

If I'm not mistaken, this PR will essentially create the same basic config file, and save it to the bundle file, only to be overwritten by most of the tests anyways. In that case rather than having an overhead of creating a config object, serializing it and saving it, isn't the current way which uses the default file from the gzip better?

@YJDoc2 Thanks for your comment 👍
At least the ones that should be generated by code should be generated by code. Otherwise, you won't know exactly what's in config.json until you unzip the file. I don't think there will be that much of a performance problem with overwriting. If you want to improve the performance, you can use a flag such as withoug_config.

[YJDoc2]

As this is mostly regarding the integration tests, I don't think we should be that much worried about performace, as in an overall sense, the most time spent will be in running actual tests rather than the config.json creation and writing. I was not enthusiastic about this, as as we have default config in file itself, and a large amount of tests already overwrite the config json, it doen't make sense to add the same default config json explicitly to all the tests manually from the code instead of zip, as for the rest of fs comes from the zip.

At least the ones that should be generated by code should be generated by code. Otherwise, you won't know exactly what's in config.json until you unzip the file. I don't think there will be that much of a performance problem with overwriting. If you want to improve the performance, you can use a flag such as without_config.

That said, I feel this is more of a stylistic issue , rather than either of the ways being a "better" way to this, so we can go forward with this.

The PR itself looks good to me 👍

[utam0k]

@YJDoc2 Thanks for thinking of this!