0

I've configured a post-receive hook in GitHub to hit the Jenkins notifyCommit URL for my repository as described here.

Any commit, on any branch, triggers that hook, which sends a polling event. Fine. Make a change to a feature branch, and Jenkins will do its poll and notice that there's nothing new to build on the job's configured branch (master), right?

But apparently, not, because even though the Jenkins job polling log says:

[poll] Last Built Revision: Revision abc123 (origin/master)

Pushing to a new branch, origin/not-master, triggers a build, whose log says:

Checking out Revision abc123 (origin/master)

So it's starting a new build for master when nothing has changed in master. Could this be a problem with how the job's repository and branch are configured? Or is this just how scheduled polling works?

Community
  • 1
  • 1
tnunamak
  • 1,989
  • 3
  • 20
  • 32

2 Answers2

1

The problem was that the build was parameterized by the branch. I wrongly assumed that either the notification would only build the branch designated by the default parameter value of master, or that it would build whichever build the notification was for.

By fixing the job's branch to master, the build trigger works as expected.

tnunamak
  • 1,989
  • 3
  • 20
  • 32
0

Due to reasons I do not know, Jenkins seems to keep track of the commits it has seen and built somewhere in the job workspace. If you are using e.g. the Workspace Cleanup plugin to delete the job workspace either in the beginning or end of the build, Jenkins will lose track of what it has built and it will initiate a new build to get back in sync.

Stop doing that. If you need to clean up the workspace, use the Git SCM "advanced behavior" dropdown and choose "Clean after checkout". This will make Jenkins run "git clean" which is a fast and safe way to clean up the workspace if the job is using git.

sti
  • 10,865
  • 1
  • 24
  • 25