Feature #1261
open
Automatically prepare builds of development branches each night
Added by Pavel Shved over 13 years ago.
Updated over 13 years ago.
Description
I'm thinking about auto-building each "current" development branch (not just master) each night. Thus, in the morning we could have a fresh build of all the development branches, which would allow us to continuously and automatically evaluate their quality at each push. This means, we may mitigate the panic we have at the end of our sprints, when we expect tests to work, but they do not. However, we don't want to lose the pace of development, and the speed we can exchange commits...
So, my proposal is like this:
- Each "current" development branch is auto-built at night (and, perhaps, it's tested with middle tests)
- At commits to this branch, small tests are executed (as with
master)
- However, commits are pushed to itgdev at once, before the tests are run for them
This way we won't lose the pace of commits exchange, and will always have results of middle and small tests for development branches. We will detect the issues earlier, and will be released from the burden of running tests manually.
What do you think?
Related issues
1 (1 open — 0 closed)
One thought is that there'll be too many simultaneous testing to avoid resolving #833 prior to this.
I just want to add that there are too many development branches at the moment and we shouldn't forget about "cleaning day".
I like the idea very much. I would not happy to have many simultaneous testing on the same machine since they can interfere by various reasons (e.g. memory limitations) that makes test results less useful.
To begin with, we can just manually configure a smaller set of development branches.
The measurements demonstrate that the average utilization of the machine during testing is about 60%. With 2Gb more memory, which a forthcoming equipment purchase will add us, machine will be utilized on 100%, the insufficient memory not being an issue anymore.
We invested a lot of time into our source:shared/sh/timeout script (see also bug #974) to mitigate issues that arise when running on an overloaded machine (unless it performs a lot of memory page swaps). Simultaneous testing of, say, two branches at a time is totally OK today.
Or, we can make the tests themselves run concurrently...
Pavel Shved wrote:
Simultaneous testing of, say, two branches at a time is totally OK today.
Two looks like a reasonable number in this configuration. I meant I would not happy to have a lot of simultaneous testing.
Alexey Khoroshilov wrote:
Two looks like a reasonable number in this configuration. I meant I would not happy to have a lot of simultaneous testing.
Well, that's a technical question (and quite easy to solve).
Also available in: Atom
PDF