[GitHub] [incubator-mxnet] lebeg commented on a change in pull request #14530: Added repeats for github status updates

[GitBox <gi...@apache.org>]

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:
users@infra.apache.org


With regards,
Apache Git Services