-
Improvement
-
Resolution: Unresolved
-
Minor
-
None
-
jenkins 2.107.3 git-plugin 3.9.0
My use case involves doing revision comparisons between two tags (each representing a successful build) for projects based on GH.
Via command-line, the way I could get the right behavior was (where test-1.0.1 and test-1.0.0 are tags created by a separate process unrelated to my particular jenkins job)
$git whatchanged --no-abbrev -M test-1.0.1 ^test-1.0.0
Using the plugin with the remote branch required only allows something like:
$ git whatchanged --no-abbrev -M test-1.0.1 ^origin/test-1.0.0
fatal: bad revision '^origin/test-1.0.0'
Perhaps there is some other trick that would allow me to gain the same effect, but I don't see the downside of this improvement in any event.
Note that the current documentation for the behavior is:
Using this behaviour will preclude the faster git ls-remote polling mechanism, forcing polling to require a workspace thus sometimes triggering unwanted builds, as if you had selected the Force polling using workspace extension as well.
So, since the plugin already requires a workspace and cannot compute the changesets solely on the remote side, I see no advantage of requiring a remote name.
- relates to
-
JENKINS-47870 git changelog compared to arbitrary reference
-
- In Progress
-
CC markewaite
jekeller Does this change allow you to compare to an arbitrary revision because you don't need to specify a remote reference. None of the code actually requires the "target" be a branch. it simple is used as the basis for "exclude" passed to git whatchanged.