Tasks #1990
Represent parallelism constraints of build systems
Status: | New | Start date: | 09/11/2014 | |
---|---|---|---|---|
Priority: | Normal | Due date: | ||
Assignee: | J. Moringen | % Done: | 0% | |
Category: | - | |||
Target version: | 1.0 |
Description
Certain build systems should not be used in parallel on the same machine. This is e.g. true for maven and ros catkin. The build generator somehow needs to respect this.
History
#1 Updated by J. Moringen over 8 years ago
Seriously? It is not possible to execute more than one maven build in parallel on the same machine (can different users use maven in parallel on the same machine?)?
If true, this has far-reaching consequences beyond generating a restricted build-flow. Consider citoolkit
, for example. With this restriction, we basically cannot have more than one distribution on that Jekins instance unless we resort to some locking strategy. But what would the scope of such a lock be, in general? The whole Jenkins instance? A particular slave?
#2 Updated by J. Wienke over 8 years ago
Jan Moringen wrote:
Seriously? It is not possible to execute more than one maven build in parallel on the same machine (can different users use maven in parallel on the same machine?)?
Normally it works but there is no guarantee that things work correctly due to the .m2/repository
folder which would then be changed in parallel by several processes, which might lead to inconsistencies. Multiple users can operate in parallel since everyone has got its own cache.
If true, this has far-reaching consequences beyond generating a restricted build-flow. Consider
citoolkit
, for example. With this restriction, we basically cannot have more than one distribution on that Jekins instance unless we resort to some locking strategy. But what would the scope of such a lock be, in general? The whole Jenkins instance? A particular slave?
Beyond the scope of one distribution this is even harder. Sure. But maybe we can first generate the build flow in a way that this is respected. The triggering of different distributions can in the first step be sequenced by timing their build correctly.
#3 Updated by J. Moringen about 8 years ago
- Target version set to 0.5
#4 Updated by J. Moringen over 6 years ago
- Target version changed from 0.5 to 0.8
#5 Updated by J. Moringen over 6 years ago
- Target version changed from 0.8 to 0.9
#6 Updated by J. Moringen about 6 years ago
- Target version changed from 0.9 to 1.0