Re: [ledgersmb-devel] Storing test-data for migrations?

On Fri, Aug 11, 2017 at 3:52 PM, Erik Huelsmann <..hidden..> wrote:

On Fri, Aug 11, 2017 at 2:54 PM, Chris Travers <..hidden..> wrote:
What about a test-data repository which could be cloned solely during specific sorts of testing?

Having a repository like that would indeed work, especially it would integrate very well with Travis CI testing as that clones recursively. I thought that people might want to clone Dojo but not our testing repo, so that this may not be a great option. On the other hand, as long as it's a separate repo, we can start out this way and change our ways when the test-data-repo gets too big. (For now, we're talking no more than a few 100 *kilo*byte...)

I'll go set up an external module reference and a repo on github to put the test data in.

Ok. We don't have to make it a sub-module. We could always clone it as part of our Travis runs explicitly.

Thanks for the feedback!

Regards,

Erik.

On Fri, Aug 11, 2017 at 1:21 PM, Erik Huelsmann <..hidden..> wrote:
Hi,

As part of a change that I'm implementing for LedgerSMB 1.2/1.3 migrations (to 1.5/1.6), I'd like to create a number of LedgerSMB database dumps for the purpose of testing those migrations.

I'm thinking that these schema files, if the scope of the tests is expanded to SL 2.8, 3.0 and 3.2, as well as tests including some *real* and *problematic* data, the test data set may become largish or even plain large (multiple MBs to multiple 10s of MBs).

While the test data sets *are* core to testing the software during development (and as part of the Continuous Integration efforts run on Travis CI), I think that putting these in each and every repository that's being cloned around the world is probably a bad idea: many of those will never be used for testing (instead they'll be used for tracking customized versions).

Some years ago, we imported the full sources of some Dojo version, which we - even though long unused - we still drag around on every clone action. To that extent, I'm thining we probably want to store these artifacts elsewhere and keep them out of the repository. Maybe starting with a directory on download.ledgersmb.org.

Any ideas/comments?

--
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.

--
Best Wishes,
Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.
http://www.efficito.com/learn_more

--
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.

Best Wishes,

Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.

http://www.efficito.com/learn_more