We used a different technique to accomplish the goal I believe you're trying to
accomplish.
Our first "smoke test" job was responsible to checkout the most recent
submission. If the job was successful at the end, we placed a tag on the git
repository and pushed the tag (with --force) to the central repository. That
tag and push was performed from a build step at the end of the "smoke test" job.
Downstream jobs performed their checkout of that specific tag. That kept all
the downstream jobs tied to the same git submission as the successful "smoke
test" job.
I'm sure there are other ways to accomplish your objective, but that worked for
us.
Mark Waite
>________________________________
> From: Anth Courtney <anthcourt...@gmail.com>
>To: jenkinsci-users@googlegroups.com
>Sent: Sunday, January 13, 2013 1:32 PM
>Subject: Re: Git plugin and checking out from a specified point in time
>
>
>Hello Mark,
>
>
>Thanks for your response. I'll investigate an 'Execute Shell' solution for the
>moment.
>
>
>The reason for wanting this ability is as part of our build pipeline.
>
>
>I want to trigger the build of a project (which lives in its own git repo) and
>once that project has built, trigger another project (which lives in another
>git repo). And so on for a number of downstream projects, each of which live
>in their own git repo.
>
>
>I am keen to ensure that all downstream projects in the pipeline are built
>from the latest checkin at the point in time that the first project was
>triggered to build, hence wanting to be able to check out at a point in time
>(the time the first build was triggered - which I would pass as a variable to
>downstream projects in the pipeline). I am trying to avoid the possibility of
>a developer checking in to a downstream build which hasn't been built yet,
>even though the pipeline has been triggered.
>
>
>There might be a better way of skinning the cat - if so, I'm obviously keen to
>hear about it.
>
>
>cheers,
>Anth
>
>
>On Mon, Jan 14, 2013 at 2:12 AM, Mark Waite <markwa...@yahoo.com> wrote:
>
>Adding a build step seems like it should work. I don't see a way from the
>plugin settings to perform a point in time checkout or even to perform a
>checkout of a specific SHA1.
>>
>>
>>Can you share why you want to take a point in time rather than the tip of a
>>branch? I'm curious about the use model and if that might be a use model
>>which would be important to others.
>>
>>
>>Mark Waite
>>
>>
>>
>>>________________________________
>>> From: "anthcourt...@gmail.com" <anthcourt...@gmail.com>
>>>To: jenkinsci-users@googlegroups.com
>>>Sent: Friday, January 11, 2013 4:33 PM
>>>Subject: Git plugin and checking out from a specified point in time
>>>
>>>
>>>
>>>Hello all,
>>>
>>>
>>>Does anyone have any pointers on how to configure a job within Jenkins (and
>>>probably more specifically, the Git plugin), so that the git checkout
>>>corresponds to a point in time. This point in time will be provided as a
>>>parameter to the build.
>>>
>>>
>>>Googling around, I have seen many references to using either:
>>>
>>>
>>>$ git checkout 'master@{2012-12-31 23:59'
>>>
>>>
>>>or
>>>
>>>
>>>$ git checkout `git rev-list -n 1 --before="2012-12-31 23:59" master`
>>>
>>>
>>>
>>>to checkout a point in time revision, but I can't see a clear way in how to
>>>then configure the jenkins job or the git plugin.
>>>
>>>
>>>Do I need to add a step like this as an execute shell step? Would I still
>>>use the git plugin to checkout master first? How will it work for subsequent
>>>builds of the same project?
>>>
>>>
>>>cheers,
>>>Anth
>>>
>>>
>
>
>
