[workflow-plugin] Groovy CPS DSL from SCM and Stash notification trigger

[Tom Deblauwe]

Hello,

I am using the "groovy CPS DSL from SCM" as my configuration for my workflow. This works well and reads the scripts from my "workflows.git" reposity.

In the workflow script itself, I start with:

node {
  git branch: '**', changelog: false, poll: true, url: 'ssh://git@stash:7999/my/project.git'
}

I have configured my Stash gitserver to notify Jenkins about a push to my code repository. In the configuration of my workflow job, I need to enable "Poll SCM" but without any timings defined for this to work.
So the problem is, that I get a notification from Stash with a commit id from the "project.git" repository(as expected), but jenkins tries to checkout that commit in the "workflows.git" repository, NOT the "project.git" repository. It doesn't exist there, so the job fails.

So how can I have my workflows scripts in a git repository, and at the same time use an external trigger to start the build?

Best regards,
Tom,

[Tom Deblauwe]

Hello,

It seems one (not so good) solution is to disable giving the SHA1 to jenkins in the hook on the Stash server that notifies Jenkins. There is an option you can disable so that the SHA1 is not given when triggering the corresponding jenkins job. Not optimal because Stash is not in control anymore about what must be built.

Best regards
Tom,

[Tom Deblauwe]

Hello again,

Just for the record: I solved it now by putting my jobs under the workflows git repo, so in a directory like this: "src/com/bla/jobs/BuildApplication.groovy" and then in that script I could make a "start()" function and then call that in the job like this:

def task = new com.bla.jobs.BuildApplication()
task.start()

So now it works with the stash git commit hook.
Best regards,
Tom,

[Kent Johnson]

Tom,

I am working out the same sort of thing with Jenkins Workflows and GitLab. It was very simple to get working for me.

All I had to do was 

1. make a new workflow job,
   
2. check the "Trigger builds remotely" box
3. set an authentication token
4. Go to my repository settings in git lab and make a web hook with my trigger URL combined with the authentication token I had previously set
5. save the job in Jenkins
6. save my configuration in Gitlab
7. commit some code
8. watch a successfully automated build

I am very pleased at how easy this all was with my self-hosted GitLab server.

[Jesse Glick]

On Monday, April 20, 2015 at 6:47:13 AM UTC-4, Tom Deblauwe wrote:

I get a notification from Stash with a commit id from the "project.git" repository(as expected), but jenkins tries to checkout that commit in the "workflows.git" repository, NOT the "project.git" repository.

I think the root problem is that this notification behaves the wrong way.

Normally commit notification such as to /git/notifyCommit simply asks Jenkins to perform polling immediately: the notification is not trusted, just taken as a hint. Then the workflow job knows how to poll properly when multiple repositories were checked out.

But if the webhook tries to schedule a build immediately, as happens when you specify a commit hash, then this cannot work. Possibly Jenkins core needs to get an API so that you can schedule polling while still suggesting a particular commit to build. Then the Git plugin would need to use this API, so that when polling is actually run, the proposed commit would be verified as legitimate and then used to check out. This would work correctly for a project with multiple repositories, because the commit hash would be rejected as nonexistent in unrelated repositories.

The real solution is probably to move away from the enforced commit hash model altogether, and instead use the multibranch API plugin to support repositories which might offer new heads on various branches.