GitSCM: AuthorInChangelog should not require workspace for polling?

Skip to first unread message


Feb 9, 2015, 8:07:00 AM2/9/15
I admit that I don't fully understand when workspace is required, but AFAICS AuthorInChangelog extension don't need it. Please correct me if I am wrong.

Anyway, my real problem is a little more complicated:

* single Git SCM configured with AuthorInChangelog (blame gerrit)
* SCM Poll configured
* slaves are on-demand Amazon instances, so they are mostly offline when build starts
* workspace is deleted after build

Now, from what I can see in this configuration every time poll fires, full build is executed. Obviously, not something I would like to get. And removing AuthorInChangelog extensions fixes everything - builds are executed only when changes are really present. Is everything OK with this scenario? Am I expecting something impossible? Please, advice.

Env data:

Jenkins: 1.595
git-client-plugin: 1.15.0
git-plugin: 2.3.3

Polling log:

Started on Feb 9, 2015 2:05:00 PM
No workspace is available, so can’t check for updates.
Scheduling a new build to get a workspace. (nonexisting_workspace)
Done. Took 36 ms
Changes found

Jesse Glick

Feb 18, 2015, 3:33:44 PM2/18/15
to Jenkins Dev
On Mon, Feb 9, 2015 at 8:06 AM, tommy.warchol <> wrote:
> Am I expecting something impossible?

I think so. Master-based polling works when Jenkins send send the
equivalent of a git-ls-remote command to the server, which gives back
a commit hash of the tip of the branch. It can compare that to the
last-built commit; if different, schedule a build. But if you want to
know *anything* about any of the intermediate commits—files changed,
authors, message—in order to decide whether to trigger a new build,
you need to find a checkout, actually pull those commits, and inspect

Compare ‘svn log <URL>’ which can get such metadata over the wire.

In the case of the Mercurial plugin, if you enable the “caches”
feature, then the pull from remote is done on a naked clone on the
master, so no workspace is required for polling even though Mercurial
also provides no way to get such metadata without pulling full commit
objects. I have suggested that the Git plugin could copy this trick.
Reply all
Reply to author
0 new messages