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.
|Field||Original Value||New Value|
|Status||Open [ 1 ]||In Progress [ 3 ]|
|Assignee||huybrechts [ huybrechts ]||cjo9900 [ cjo9900 ]|
|Status||In Progress [ 3 ]||Resolved [ 5 ]|
|Resolution||Fixed [ 1 ]|
|Workflow||JNJira [ 144320 ]||JNJira + In-Review [ 191028 ]|