Mark a build as DUPLICATED (same version) only it's close in time #7420
Conversation
Instead of checking for "any other build for this verion in TRIGGRERED state" we also add the filter for builds triggered in the previous 5 minutes. This allows us to avoid false positives for builds that failed for any reason and didn't update their state, ending up on blocked builds for that version (all the builds were marked as DUPLICATED in that case). Adding this date condition, we reduce the risk of hitting this problem to 5 minutes only. If the build takes more than 5 minutes to complete, users could end up with builds building exacly the same version (and commit); but this is how it works right now without this DEDUPLICATE_BUILDS feature. So, I think it's still an improvement to avoid builds triggered in flood.
| @@ -184,6 +184,7 @@ def prepare_build( | |||
| project=project, | |||
| version=version, | |||
| state=BUILD_STATE_TRIGGERED, | |||
| date__gte=timezone.now() - datetime.timedelta(minutes=5), | |||
There was a problem hiding this comment.
This could use a comment explaining why 5 mins, or pointing to this PR.
Seems we could adjust this to be the normal build time length, but that would add some queries.
There was a problem hiding this comment.
+1 on the comment.
Seems we could adjust this to be the normal build time length, but that would add some queries.
I thought about this, but using the build time of the project, you end up waiting 15 or more before being able to trigger a new build when there is a staled build. In the end, it's not too much different than our task finish_inactive_builds.
Oh, looking at that task it seems we changed the max time for a build to be considered stale to 2hs! It was DOCKER_LIMIT['time'] * 1.2 originally. I think we can revert this changes now that we have the right docker limits in the dictionary: #7029
There was a problem hiding this comment.
finish_inactive_builds doesn't stop the builds from happening on the builders, it just updates the status of the Build object. They are solving different problems.
There was a problem hiding this comment.
Right, but finish_inactive_builds is the task that "unblocks" the DEDUPLICATE_BUILDS feature flag to start working again (not marking all of them as duplicated) by updating the state to something different than triggered. Now, it's unblocking these builds after more than 2hs of stale.
There was a problem hiding this comment.
Ah, I see. That makes sense.
humitos
force-pushed
the
humitos/duplicate-builds-within-window-time
branch
from
24ca5c2 to
950010a
Compare
Instead of checking for "any other build for this verion in TRIGGRERED state" we
also add the filter for builds triggered in the previous 5 minutes. This allows
us to avoid false positives for builds that failed for any reason and didn't
update their state, ending up on blocked builds for that version (all the builds
were marked as DUPLICATED in that case).
Adding this date condition, we reduce the risk of hitting this problem to 5
minutes only.
If the build takes more than 5 minutes to complete, users could end up with
builds building exacly the same version (and commit); but this is how it works
right now without this DEDUPLICATE_BUILDS feature. So, I think it's still an
improvement to avoid builds triggered in flood.