Multi branch pipeline with slave: path to ".git" folder for each branch

182 views
Skip to first unread message

Elifarley Cruz

unread,
Sep 27, 2017, 8:11:35 PM9/27/17
to Jenkins Users
I have a multibranch pipeline job that runs on a Linux slave. The source code comes from a git repo at BitBucket.

Now, 3 questions:

1) I suppose that, for each new build, a "git pull" or similar is executed, instead of a more expensive "git clone". Am I right?

2) Furthermore, I guess the "git pull" is executed twice: one at the master, and one at the slave. Is that true?

3) If so, after the build is done, how can I get the path to the .git folder on the master and also on the slave?

Thanks!

Mark Waite

unread,
Sep 27, 2017, 8:39:34 PM9/27/17
to jenkins...@googlegroups.com
On Wed, Sep 27, 2017 at 6:11 PM Elifarley Cruz <elif...@gmail.com> wrote:
I have a multibranch pipeline job that runs on a Linux slave. The source code comes from a git repo at BitBucket.

Now, 3 questions:

1) I suppose that, for each new build, a "git pull" or similar is executed, instead of a more expensive "git clone". Am I right?


Yes, you're right.  The git plugin detects if the workspace already contains a git repository.  If a git repository is detected, then that repository is updated rather than being cloned again.
 
2) Furthermore, I guess the "git pull" is executed twice: one at the master, and one at the slave. Is that true?


if the multibranch pipeline is using the Bitbucket branch source plugin, it may be using Bitbucket API's to retrieve a single file (the Jenkinsfile) rather than cloning the entire repository on the master.

If the multibranch pipeline is using the git implementation, it doesn't know those API's, so it will clone the full repository to the master.
 
3) If so, after the build is done, how can I get the path to the .git folder on the master and also on the slave?


Please don't perform operations in the repository on the master.  It is not intended for use by anything other than Jenkins itself.  

We've had several different problems reported by users who mistakenly thought they could use the copy of the repository on the master.

On the agent, the .git folder is in the workspace directory.  If you use a dir("xx") { } wrapper around the checkout, then the .git folder will be placed inside that directory.

Can you explain why you need the location of the .git folder on the agent?  Even more, can you explain why you need the location of the .git folder on the agent?

Mark Waite
 
Thanks!

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/69a50419-c5ff-4a3b-b919-ab4f8f7658db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Elifarley Cruz

unread,
Sep 28, 2017, 10:16:11 AM9/28/17
to Jenkins Users
Thanks for the info, Mark!

One of the reasons I asked for these locations is that I wanted to learn more about how Jenkins works.

Another reason is that I initially thought about using it to create a "release notes"-like text containing the Jira issues that were resolved between the last build and the current one (as each commit should have a Jira issue ID in it).

But I guess there are better ways to achieve this...

Mark Waite

unread,
Sep 28, 2017, 10:24:52 AM9/28/17
to jenkins...@googlegroups.com
On Thu, Sep 28, 2017 at 8:16 AM Elifarley Cruz <elif...@gmail.com> wrote:
Thanks for the info, Mark!

One of the reasons I asked for these locations is that I wanted to learn more about how Jenkins works.


That's a good reason.  Good for you for asking.
 
Another reason is that I initially thought about using it to create a "release notes"-like text containing the Jira issues that were resolved between the last build and the current one (as each commit should have a Jira issue ID in it).


I think you can get that result with "git" commands in the workspace, without needing to know the location of the workspace, or the location of the git repository in that workspace.  

It isn't that the location is an intentional secret, but the location is already abstracted away for the user by command line git.

Mark Waite
 
Reply all
Reply to author
Forward
0 new messages