lebeg commented on a change in pull request #14530: Added repeats for github
status updates
URL: https://github.com/apache/incubator-mxnet/pull/14530#discussion_r269983096
##########
File path: ci/Jenkinsfile_utils.groovy
##########
@@ -186,18 +186,27 @@ def update_github_commit_status(state, message) {
context = get_github_context()
echo "context=${context}"
- step([
- $class: 'GitHubCommitStatusSetter',
- reposSource: [$class: "ManuallyEnteredRepositorySource", url: repoUrl],
- contextSource: [$class: "ManuallyEnteredCommitContextSource", context:
context],
- commitShaSource: [$class: "ManuallyEnteredShaSource", sha: commitSha],
- statusBackrefSource: [$class: "ManuallyEnteredBackrefSource", backref:
"${env.RUN_DISPLAY_URL}"],
- errorHandlers: [[$class: 'ShallowAnyErrorHandler']],
- statusResultSource: [
- $class: 'ConditionalStatusResultSource',
- results: [[$class: "AnyBuildResult", message: message, state: state]]
- ]
- ])
+ // a few attempts need to be made:
https://github.com/apache/incubator-mxnet/issues/11654
+ for (int attempt = 1; attempt < 4; attempt++) {
+ echo "Sending GitHub status attempt ${attempt}..."
+
+ step([
Review comment:
@vishaalkapoor I mentioned the answers in the description, but here they are
again explicitly:
> (why) will this step be repeated if it's successful? is there a way to see
if the step succeeded and not iterate?
There is no known to me way to determine if step was a success. In case of a
real failure the step just does nothing - the list of repositories it needs to
update is empty.
> is the operation idempotent (in the event you cannot determine if the step
succeeded and are forced to do the step several times)?
I needed to look in Wikipedia what
[Idempotence](https://en.wikipedia.org/wiki/Idempotence) actually is and found
out that yes, the operation is idempotent.
> What kind of outages is the backoff strategy aiming to mitigate and what
is the duration and cause of those outages?
The repository object can not be fetched from a
[cache](https://github.com/jenkinsci/github-plugin/blob/26ac9b0d1c4702f5d0940201a7e8deb19d5a42c6/src/main/java/com/cloudbees/jenkins/GitHubRepositoryName.java#L163-L167)
for some reason by
[GitHubCommitStatusSetter](https://github.com/jenkinsci/github-plugin/blob/497f43251e3bfc130f125f75e45f73e06894361d/src/main/java/org/jenkinsci/plugins/github/status/GitHubCommitStatusSetter.java).
This happens once in a while and became a significant problem because we have
split the pipelines.
> Is the backoff of 1 second x 3 empirically effective? Have you considered
different strategies?
We are aiming to test that on all the PR's. For the test job it didn't fail
at all. If this simple strategy will not be enough we might look into other.
> is there a more robust way to handle this planned?
Potentially
[another](https://wiki.jenkins.io/display/JENKINS/GitHub+Integration+Plugin)
plugin might be used when it will be mature enough. Currently it doesn't work
since it can not be configured properly.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
