[JIRA] (JENKINS-13852) Allow speciying Git SHA1 commit id for next build(s) as Predefined parameter

[cjo9...@java.net (JIRA)]

cjo9900 commented on JENKINS-13852 Allow speciying Git SHA1 commit id for next build(s) as Predefined parameter The action to pass "Pass-through Git commit that was build" gets the SubversionTagAction from the current build and then creates a RevisionParameterAction that is passed to the downstream build. The SubversionTagAction[4] is created by the GIT SCM plugin to indicate what revision it set the workspace to. The GIT SCM uses the RevisionParameterAction[2] to determine the commit to set the revision to, if passed in. In the case you mention where you need to pass the commit id from job A to job C via job B, but the plugin does not pass the RevisionParameterAction that is passed into job B down to job C. As the RevisionParameterAction stores a list of SVNInfos (repo url + commit_id)[3], there could be the possibility to just taking the RevisionParameterAction that is passed to job B from job A and merge the contents of it with the revisions in SubversionTagAction generated by job B. [1] https://github.com/jenkinsci/parameterized-trigger-plugin/blob/master/src/main/java/hudson/plugins/parameterizedtrigger/SubversionRevisionBuildParameters.java [2] https://github.com/jenkinsci/subversion-plugin/blob/master/src/main/java/hudson/scm/RevisionParameterAction.java [3] https://github.com/jenkinsci/subversion-plugin/blob/master/src/main/java/hudson/scm/SubversionSCM.java#L894 [4] https://github.com/jenkinsci/subversion-plugin/blob/master/src/main/java/hudson/scm/SubversionTagAction.java

This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira