[#QB-2535] New builds are triggered automatically without a commit after build cleanup strategy has cleaned all historical builds

QuickBuild

New builds are triggered automatically without a commit after build cleanup strategy has cleaned all historical builds

Created: 08/Sep/15 10:49 AM Updated: 17/Dec/15 06:17 AM

Component/s:

None

Affects Version/s:

6.0.27

Fix Version/s:

None

Original Estimate:

Unknown

Remaining Estimate:

Unknown

Time Spent:

Unknown

Description

« Hide

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.

All

Comments

Work Log

Change History

Sort Order:

[ 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.

[ Permlink | « Hide ]

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?

[ Permlink | « Hide ]

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.

[ Permlink | « Hide ]

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.

[ Permlink | « Hide ]

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;