Details

Description

Consider a stream of jobs: A - B - C

We can parameterize to build B with the same git commit SHA1 as A by adding "Pass-through Git commit that was build" parameter in A. However, this only works for subsequent jobs. There is no way to configure what SHA1 C will use.

In our case, the B uses a different Git repository than A, while C again uses the same repository as A. We would need to parameterize the stream so that A and C use the same revision.

I tried manually setting GIT_COMMIT variable through "Predefined parameters" in A. Using 'env' as a shell script in B, I can see that GIT_COMMIT environment property gets correctly set, however, it doesn't seem to have any effect. Maybe this is because parameters kick in only after Git checkout, so that the default (empty) GIT_COMMIT is used for checkout and GIT_COMMIT is only set to what was passed after that.

Anyway, would be nice to be able to manually set the GIT_COMMIT through "Predefined parameters" instead of having to use the "Pass-through Git commit that was build". I think that be quite flexible solution.

Attachments

Activity

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.

cjo9900
added a comment - 2012-11-09 18:36 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