-
Notifications
You must be signed in to change notification settings - Fork 146
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cleanup tests #177
Cleanup tests #177
Conversation
assertThat("At least the rate implied delay but no more than 500ms longer", | ||
secondBuild.getStartTimeInMillis() - firstBuild.getStartTimeInMillis(), | ||
allOf( | ||
greaterThanOrEqualTo(60 * 60 / rate * 1000L - 200L), | ||
lessThanOrEqualTo(60 * 60 / rate * 1000L * 500L) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The *
in the less than condition from the comment seems to be a typo
I tested this locally and i got a mind boggling result
|
@@ -169,13 +170,14 @@ public void rateLimitsBlockBuilds(int rate) throws Exception { | |||
); | |||
assertThat(master.isInQueue(), is(false)); | |||
assertThat(master.getQueueItem(), nullValue()); | |||
assertThat(master.getBuilds().getLastBuild(), isNotNull()); | |||
long startTime = master.getBuilds().getLastBuild().getTimeInMillis(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is probably why it flakes all the time lastBuild is not null so it uses the time of the last build to throttle
branch-api-plugin/src/main/java/jenkins/branch/RateLimitBranchProperty.java
Lines 507 to 530 in a1c604b
Run lastBuild = job.getLastBuild(); | |
if (lastBuild != null) { | |
// we don't mind if the project type allows concurrent builds | |
// we assume that the last build was started at a time that respects the rate | |
// thus the next build to start will start such that the time between starts matches the rate | |
// it doesn't matter if the duration of the build is longer than the time between starts | |
// only that we linearise the starts and keep a consistent minimum duration between *starts* | |
long timeSinceLastBuild = System.currentTimeMillis() - lastBuild.getTimeInMillis(); | |
long betweenBuilds = property.getMillisecondsBetweenBuilds(); | |
if (timeSinceLastBuild < betweenBuilds) { | |
LOGGER.log(Level.FINE, "{0} will be delayed for another {1}ms as it is {2}ms since " | |
+ "last build and ideal rate is {3}ms between builds", | |
new Object[]{ | |
job.getFullName(), | |
betweenBuilds - timeSinceLastBuild, | |
timeSinceLastBuild, | |
betweenBuilds | |
} | |
); | |
return CauseOfBlockage.fromMessage(Messages._RateLimitBranchProperty_BuildBlocked( | |
new Date(lastBuild.getTimeInMillis() + betweenBuilds)) | |
); | |
} | |
} |
I watch with interest... |
Now i always run into a different error. 😅 |
Huzzah it worked |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, so you got it to succeed once. Does this mean the tests aren't flaky now?
It shouldn't be flaky as it stopped flaking on my local machine the one with
So at least for this flake it should stop, it was root caused in my previous comment as well. So I expect the flaking for this particular test to stop |
doYank()
methodRunning it in CI to try to reproduce all the test flakes