[JIRA] (JENKINS-37880) Starting, stopping and replaying a run in quick succession does not work

10 views
Skip to first unread message

jdumay@cloudbees.com (JIRA)

unread,
Sep 1, 2016, 12:23:01 AM9/1/16
to jenkinsc...@googlegroups.com
James Dumay created an issue
 
Jenkins / Bug JENKINS-37880
Starting, stopping and replaying a run in quick succession does not work
Issue Type: Bug Bug
Assignee: Vivek Pandey
Components: blueocean-plugin
Created: 2016/Sep/01 4:22 AM
Priority: Minor Minor
Reporter: James Dumay

Steps to reproduce

  1. Create a new multi-branch pipeline using https://github.com/i386/hellonode
  2. Go to the branches screen
  3. Trigger a new build for master
  4. Open the run and click stop
  5. Then click replay again

The goal here is to try starting, stopping then replaying really quickly.

You will get a 500 error back from the replay action

PUT http://localhost:8080/jenkins/blue/rest/organizations/jenkins/pipelines/hellonode/branches/master/runs/23/replay/ 500 (Server Error)

Unknown macro: { "message" }

I attached a debugger when reproducing and got org.jenkinsci.plugins.workflow.cps.replay.ReplayAction#run2 returning null. Digging deeper it appears we can't get the flow owner

private @CheckForNull CpsFlowExecution getExecution() {
        FlowExecutionOwner owner = ((FlowExecutionOwner.Executable) run).asFlowExecutionOwner();
        if (owner == null) {
            return null;
        }
        FlowExecution exec = owner.getOrNull();
        return exec instanceof CpsFlowExecution ? (CpsFlowExecution) exec : null;
    }

I suspect this is a bug in workflow?

Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

vivek.pandey@gmail.com (JIRA)

unread,
Sep 1, 2016, 12:33:01 AM9/1/16
to jenkinsc...@googlegroups.com
Vivek Pandey commented on Bug JENKINS-37880
 
Re: Starting, stopping and replaying a run in quick succession does not work

James Dumay that code looks alright, instanceof is false if the value being checked is null. I need to look in to it whats causing this failure.

vivek.pandey@gmail.com (JIRA)

unread,
Sep 1, 2016, 3:41:01 PM9/1/16
to jenkinsc...@googlegroups.com

James Dumay It looks legit failure. In debugger I see it logging with FINE level "java.util.concurrent.ExecutionException: org.jenkinsci.plugins.github_branch_source.RateLimitExceededException: GitHub API rate limit exceeded". Perhaps it should be logged as error and maybe thrown as exception so that callers know what went wrong instead of getting null execution instance.

@Override public FlowExecution getOrNull() {
            try {
                ListenableFuture<FlowExecution> promise = run().getExecutionPromise();
                if (promise.isDone()) {
                    return promise.get();
                }
            } catch (Exception x) {
                LOGGER.log(/* not important */Level.FINE, null, x); //Vivek: This is where its print what went wrong
            }

vivek.pandey@gmail.com (JIRA)

unread,
Sep 1, 2016, 3:42:03 PM9/1/16
to jenkinsc...@googlegroups.com
Vivek Pandey edited a comment on Bug JENKINS-37880
[~jamesdumay] It looks legit failure. In debugger I see it its logging with FINE level "java.util.concurrent.ExecutionException: org.jenkinsci.plugins.github_branch_source.RateLimitExceededException: GitHub API rate limit exceeded" and eats away the exception . Perhaps it should be logged as error and maybe thrown as exception so that callers know what went wrong instead of getting null execution instance.

{code:java}

@Override public FlowExecution getOrNull() {
            try {
                ListenableFuture<FlowExecution> promise = run().getExecutionPromise();
                if (promise.isDone()) {
                    return promise.get();
                }
            } catch (Exception x) {
                LOGGER.log(/* not important */Level.FINE, null, x); //Vivek: This is where its print what went wrong
            }
{code}

jdumay@cloudbees.com (JIRA)

unread,
Sep 1, 2016, 8:10:01 PM9/1/16
to jenkinsc...@googlegroups.com

jdumay@cloudbees.com (JIRA)

unread,
Sep 1, 2016, 8:28:01 PM9/1/16
to jenkinsc...@googlegroups.com
James Dumay commented on Bug JENKINS-37880
 
Re: Starting, stopping and replaying a run in quick succession does not work

Vivek Pandey I think bubbling more info up to the client here would be the right way to go. Then we can follow up with a UI story to display the error to the user. WDYT?

vivek.pandey@gmail.com (JIRA)

unread,
Sep 1, 2016, 9:01:02 PM9/1/16
to jenkinsc...@googlegroups.com

Right, this needs to be fixed in underlying pipeline plugin, once it's thrown as exception then BO API can send that error back to UI.

jdumay@cloudbees.com (JIRA)

unread,
Sep 1, 2016, 9:30:03 PM9/1/16
to jenkinsc...@googlegroups.com

jdumay@cloudbees.com (JIRA)

unread,
Sep 6, 2016, 10:29:01 PM9/6/16
to jenkinsc...@googlegroups.com

Vivek Pandey Michael Neale I found another case where replay doesn't work (500 is received).

I believe this run had a problem connecting to Github and is now un-replayable.

Started by user James Dumay
Connecting to https://api.github.com using i386/******
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from 2 remote Git repositories
 > git config remote.origin.url https://github.com/i386/app-store-demo.git # timeout=10
Fetching upstream changes from https://github.com/i386/app-store-demo.git
 > git --version # timeout=10
using .gitcredentials to set credentials
 > git config --local credential.username i386 # timeout=10
 > git config --local credential.helper store --file=/var/folders/11/5vmtkd9j6kd3w6sbrsrw0sh80000gn/T/git561487727535648502.credentials # timeout=10
 > git -c core.askpass=true fetch --tags --progress https://github.com/i386/app-store-demo.git +refs/heads/*:refs/remotes/origin/*
 > git config --local --remove-section credential # timeout=10
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from https://github.com/i386/app-store-demo.git
	at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:799)
	at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1055)
	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1086)
	at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109)
	at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:108)
	at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:85)
	at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:207)
	at hudson.model.ResourceController.execute(ResourceController.java:98)
	at hudson.model.Executor.run(Executor.java:404)
Caused by: hudson.plugins.git.GitException: Command "git -c core.askpass=true fetch --tags --progress https://github.com/i386/app-store-demo.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: fatal: unable to access 'https://github.com/i386/app-store-demo.git/': Couldn't connect to server

	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1740)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1476)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:63)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:314)
	at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:797)
	... 8 more

GitHub has been notified of this commit’s build result

ERROR: null
Finished: FAILURE

mneale@cloudbees.com (JIRA)

unread,
Sep 7, 2016, 12:48:01 AM9/7/16
to jenkinsc...@googlegroups.com

jdumay@cloudbees.com (JIRA)

unread,
Sep 7, 2016, 12:54:01 AM9/7/16
to jenkinsc...@googlegroups.com

Michael Neale replay seems to only work if the flow graph was persisted correctly to disk. If it is not there (in the case of there being no flow nodes in the last example) then it fails.

vivek.pandey@gmail.com (JIRA)

unread,
Sep 7, 2016, 12:55:01 AM9/7/16
to jenkinsc...@googlegroups.com

James Dumay In this case 500 is correct error, no? Its un-replayble - what do you mean, is it 500 error every time you click replay or something else? Might be worth checking with Ivan Meredith, think he wrote replay functionality in pipeline plugin.

vivek.pandey@gmail.com (JIRA)

unread,
Sep 7, 2016, 12:55:02 AM9/7/16
to jenkinsc...@googlegroups.com
Vivek Pandey edited a comment on Bug JENKINS-37880
[~jamesdumay] In this case 500 is correct error, no? Its un-replayble - what do you mean, is it 500 error every time you click replay or something else? Might be worth checking with [~imeredith], think he wrote replay functionality in pipeline plugin.

jdumay@cloudbees.com (JIRA)

unread,
Sep 7, 2016, 12:57:01 AM9/7/16
to jenkinsc...@googlegroups.com

Vivek Pandey yes, all of these cases received a 500.

Ivan Meredith / Vivek Pandey it would be nice we could sidestep this stuff for replay. Take the commit Ids from the run that is being replayed, ask Jenkins to build those, etc (allowing it to read the Jenkinsfile again instead of using the previous pipeline state).

Probably easier said than done?

jdumay@cloudbees.com (JIRA)

unread,
Sep 8, 2016, 8:50:06 PM9/8/16
to jenkinsc...@googlegroups.com

jdumay@cloudbees.com (JIRA)

unread,
Sep 8, 2016, 8:50:06 PM9/8/16
to jenkinsc...@googlegroups.com

jdumay@cloudbees.com (JIRA)

unread,
Sep 23, 2016, 1:53:04 AM9/23/16
to jenkinsc...@googlegroups.com

jdumay@cloudbees.com (JIRA)

unread,
Sep 27, 2016, 9:50:01 PM9/27/16
to jenkinsc...@googlegroups.com

jdumay@cloudbees.com (JIRA)

unread,
Feb 16, 2017, 4:08:01 PM2/16/17
to jenkinsc...@googlegroups.com
James Dumay resolved as Won't Do
Change By: James Dumay
Status: Open Resolved
Resolution: Won't Do

jdumay@cloudbees.com (JIRA)

unread,
Mar 21, 2017, 8:03:03 PM3/21/17
to jenkinsc...@googlegroups.com
James Dumay resolved as Duplicate
Change By: James Dumay
Status: Reopened Resolved
Resolution: Duplicate
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

jdumay@cloudbees.com (JIRA)

unread,
Mar 21, 2017, 8:03:04 PM3/21/17
to jenkinsc...@googlegroups.com
James Dumay reopened an issue
Change By: James Dumay
Resolution: Won't Do
Status: Resolved Reopened

jbriden@cloudbees.com (JIRA)

unread,
Jul 6, 2018, 5:06:28 PM7/6/18
to jenkinsc...@googlegroups.com
Jenn Briden closed an issue as Duplicate
Change By: Jenn Briden
Status: Resolved Closed
This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)
Reply all
Reply to author
Forward
0 new messages