|
|
|
[
Permlink
| « Hide
]
Robin Shen [08/Sep/15 11:38 PM]
As you've discovered the first build will always be created if scheduled time reaches, as QB has to use the first build as base for change calculation. QB does not record current commit in configuration as otherwise it is not possible to back to some old commits by deleting builds which is necessary for some workflows.
Why is nog possible to keep always at least one build in history for this situation? For example I am now forced to do a complex setup to be able to use the cleanup for days and stille remaind on historical build. Any plan to change this approach?
Do you mean that in case of build cleanup, QB should preserve at least one build in history for this purpose? That is because QB has to respect the build cleanup as well as the schedule build condition. So you may cleanup all builds, but QB will generate one if scheduled time reaches (or you can customize the build contion so that it does not generate one automatically), or never generate one if the build is not scheduled.
That is exactly what I mean, it makes no sense to build twice a same changeset just because your history is wiped. Also the example made that it should be possible to remove some builds to go back to old commits, how will that work as it will just move from the last build to head revision basicly.
Build cleanup and build firing based on condition are two independent mechanism. If you do not want to have QB generate the first build after wiping, you may change the build condition something like below:
groovy: if (configuration.getLatestBuild() == null) return false; // do not run build automatically if there is no build in history for (repo in configuration.getReferencedRepositories()) { if (repo.isChanged()) return true; } return false; |