| << Back to previous view |
|
[QB-2535] New builds are triggered automatically without a commit after build cleanup strategy has cleaned all historical builds
|
|
| Status: | Closed |
| Project: | QuickBuild |
| Component/s: | None |
| Affects Version/s: | 6.0.27 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Maikel vd Hurk | Assigned To: | Robin Shen |
| Resolution: | Won't Fix | Votes: | 0 |
| Remaining Estimate: | Unknown | Time Spent: | Unknown |
| Original Estimate: | Unknown | ||
| Description |
|
New builds are triggered automatically without a commit after build cleanup strategy has cleaned all historical builds. For example:
ConfigurationA is containing build versions 1 (created a two weeks ago), 2 (created a week ago) If there are no new commits done and your Build Cleanup Strategy is stating Reserve builds by days Reserve Days 4. Then after this 4 days are passed both build versions (1 and 2) are removed correctly, but QuickBuild will also decide to create a new version (which is identical to version 2) despite the fact there are no new commits done based on the fact it can't calculate if there is anything to be done as there is no previous build to evaluate against. This is rather odd and I would expect that we will always keep reference on what the last commit was which was build rather then just for safety recreate it, because there was no previous build present. |
| Comments |
| Comment by 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. |
| Comment by Maikel vd Hurk [ 09/Sep/15 09:48 PM ] |
| 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? |
| Comment by Robin Shen [ 09/Sep/15 11:22 PM ] |
| 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. |
| Comment by Maikel vd Hurk [ 10/Sep/15 03:01 PM ] |
| 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. |
| Comment by Robin Shen [ 10/Sep/15 10:05 PM ] |
|
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; |