Details
-
Bug
-
Status: Open (View Workflow)
-
Minor
-
Resolution: Unresolved
-
None
-
-
Blue Ocean - Candidates
Description
Problem
Non-multibranch pipelines do not have any changeset information
Steps to reproduce
- Create a Pipeline using the Jenkinsfile below
- Run the Pipeline
- There is no revision information
Jenkinsfile
node {
stage('checkout') {
checkout([$class: 'SubversionSCM',
locations: [[local: '.', remote: 'http://svn.apache.org/repos/asf/poi/trunk/sonar/']],
workspaceUpdater: [$class: 'UpdateUpdater']
])
}
}
Original request
(See https://groups.google.com/forum/?utm_source=footer#!topic/jenkinsci-users/FwBdR0UB6Qc)
In BlueOcean (v1.2.0) pipeline activity view the column 'COMMIT' always only shows a '-' (dash):
- Is that okay or what should be shown there?
- Side note: it is a "Pipeline from SCM" using SVN.
Please note that in the 'Changes' tab the SVN commit is nicely listed with SVN commit ID and message though: 
Attachments
Issue Links
- is related to
-
JENKINS-44869 Activity tabs Run id column should expand to fit value
-
- Open
-
Activity
SCMRevisionAction is specific to multibranch builds and represents the one commit which the multibranch folder is tracking and from which Jenkinsfile etc. are taken—what checkout scm would check out. If you have a non-multibranch project, including freestyle as well as Pipeline, or even want to account for SCM information from other checkout (incl. git) steps used in a multibranch build, you can use RunWithSCM.getChangeSets and ChangeLogSet.Entry.getCommitId.
To be clear, RunWithSCM.getChangeSets should represent the complete changelog for this build, including whatever commits might be included in the diff of SCMRevisionAction from the previous build to this one, assuming checkout scm was run at least once. From a technical perspective, this issue is not a bug at all—the changelog is displayed if there is any (which there would not be for e.g. build #1 or if you just retriggered a build manually); and the unique commit ID is displayed if there is any (which there would not be for a non-multibranch build, since these may check out zero or more repositories in various revisions according to whim). It is just a design decision what sorts of metadata you wish to display in builds under various circumstances that you think would best match user expectations.
Hrm. And that that brings up another point, pipelines can have multiple scms hooked up to it (multiple git repos, git and svn, what have you)....
Maybe its better just to hide the column if its not a multi branch pipeline.
Reinhold Füreder
added a comment - Thanks for the insider/background information (and the hint in JENKINS-44869):
- well, yes, actually I (therefore) have the commit ID (SVN revision or shortened GIT commit hash) as suffix of my therefore quite long build display number, e.g. "20170613-161100-rev134098" (i.e. "<date>-<time>-rev<SVN revision>")
- and thus hiding the "Commit" column for a non-multi branch pipeline in favour of showing the full build display number in the BO's activity tab "Run" id column (see JENKINS-44869) would be ideal/fine for me
Reinhold Füreder
added a comment - Thanks for the insider/background information (and the hint in JENKINS-44869 ):
well, yes, actually I (therefore) have the commit ID (SVN revision or shortened GIT commit hash) as suffix of my therefore quite long build display number, e.g. "20170613-161100-rev134098" (i.e. "<date>-<time>-rev<SVN revision>")
and thus hiding the "Commit" column for a non-multi branch pipeline in favour of showing the full build display number in the BO's activity tab "Run" id column (see JENKINS-44869 ) would be ideal/fine for me
https://github.com/jenkinsci/blueocean-plugin/blob/70083b199cf41486dd0559520f0764205ea67ac3/blueocean-pipeline-api-impl/src/main/java/io/jenkins/blueocean/rest/impl/pipeline/PipelineRunImpl.java#L209-L216
Looks like blueocean pulls the commit id from the run, using the SCMRevisionAction, which at least svn doesn't seem to populate.
stephenconnolly jglick looks like you worked on SCMRevisionAction, is that the right way to pull commit info for a run? it looks like its only implemented in workflow-multibranch-plugin, literate-plugin and yaml-project-plugin. Are other scm providers supposed to implement this?