[JIRA] (JENKINS-36453) Replay does not reuse commit on non-multibranch pipeline jobs

2 views
Skip to first unread message

ivan@ivan.net.nz (JIRA)

unread,
Jul 5, 2016, 6:02:04 PM7/5/16
to jenkinsc...@googlegroups.com
Ivan Meredith created an issue
 
Jenkins / Improvement JENKINS-36453
Replay does not reuse commit on non-multibranch pipeline jobs
Issue Type: Improvement Improvement
Assignee: Jesse Glick
Components: workflow-plugin
Created: 2016/Jul/05 10:01 PM
Priority: Minor Minor
Reporter: Ivan Meredith

In multibranch jobs, if you 'replay' a build it will reuse the git commit (and assume svn revision etc) of the build in the replay.

But with non-multibranch pipeline jobs, the latest commit is always used no matter what build is replayed.

It may have something to do with 'checkout scm' vs 'git url:' being used, but either way I think it should work ine same.

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

ivan@ivan.net.nz (JIRA)

unread,
Jul 7, 2016, 11:58:01 PM7/7/16
to jenkinsc...@googlegroups.com
Ivan Meredith updated an issue
Change By: Ivan Meredith
In multibranch jobs, if you 'replay' a build it will reuse the git commit (and assume svn revision etc) of the build in the replay.

But with non-multibranch pipeline jobs, the latest commit is always used no matter what build is replayed.

It may have something to do with 'checkout scm' vs 'git url:' being used, but either way I think it should work ine in the same.

jglick@cloudbees.com (JIRA)

unread,
Mar 23, 2017, 11:21:02 AM3/23/17
to jenkinsc...@googlegroups.com
Jesse Glick assigned an issue to Unassigned
 

Replay is actually not the central issue. scm for a CpsScmFlowDefinition is not guaranteed to match the commit of Jenkinsfile. This is because it is using hudson.model.SCM, i.e., the old core APIs, which do not support checking out a specific version. In order to fix this we would have to actually deprecate CpsScmFlowDefinition and provide a replacement using scm-api so it would behave more like multibranch, except of course for a predefined branch.

Jenkins / New Feature JENKINS-36453
Change By: Jesse Glick
Issue Type: Improvement New Feature
Component/s: workflow-cps-plugin
Component/s: pipeline
Assignee: Jesse Glick
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

jdumay@cloudbees.com (JIRA)

unread,
Mar 23, 2017, 4:55:01 PM3/23/17
to jenkinsc...@googlegroups.com
James Dumay commented on New Feature JENKINS-36453
 
Re: Replay does not reuse commit on non-multibranch pipeline jobs

Jesse Glick great explanation I think we are going to put less emphasis on this job type in the UI in the future so I'd imagine this isn't as high priority as I thought it might be.

nicos.maris@gmail.com (JIRA)

unread,
Mar 13, 2018, 11:23:03 AM3/13/18
to jenkinsc...@googlegroups.com

brian.murrell@intel.com (JIRA)

unread,
May 6, 2020, 11:58:04 AM5/6/20
to jenkinsc...@googlegroups.com

Replay is actually not the central issue. scm for a CpsScmFlowDefinition is not guaranteed to match the commit of Jenkinsfile. This is because it is using hudson.model.SCM, i.e., the old core APIs, which do not support checking out a specific version. In order to fix this we would have to actually deprecate CpsScmFlowDefinition and provide a replacement using scm-api so it would behave more like multibranch, except of course for a predefined branch.

Is this why, when I Replay a given build of a given multi-branch pipeline job, the Jenkinsfile is checked out at the commit build I'm Replaying was at, however a checkout in the pipeline job does not get the same commit? Is it because the scm.branches doesn't point at the commit of the Replay but rather points at the branch?

If so, this is pretty horrible. Shouldn't one be able to depend on the global scm variable containing an accurate representation of what is being checked out (implicitly)? Why does the implicit checkout get the right commit and yet an explicit checkout doesn't?

This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages