# Commit pipeline for local git repo

**URL:** <https://community.jenkins.io/t/commit-pipeline-for-local-git-repo/11840>\
**Category:** Ask a question\
**Created:** [January 17, 2024, 2:31am UTC](https://community.jenkins.io/t/commit-pipeline-for-local-git-repo/11840 "2024-01-17T02:31:05Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![lipton](https://avatars.discourse-cdn.com/v4/letter/l/c67d28/32.png) [@lipton](https://community.jenkins.io/u/lipton)\
**Post date:** [January 17, 2024, 2:31am UTC](https://community.jenkins.io/t/commit-pipeline-for-local-git-repo/11840/1 "2024-01-17T02:31:05Z")

</div>

Jenkins setup: version 2.426.2  
OS: Ubuntu 22.04 LTS

Greetings,

I am creating a simple commit pipeline for an existing local crosstool-ng git repository. Probably due to my naive views on how Jenkins operates, I am not able to reference that existing file structure, which is outside of /var/lib/jenkins/workspace. I am not even able to switch to that directory, in order to run a build.  
I don’t mind doing my own work and reading whatever guide is available, just don’t see a book detailed enough with information on Linux and Jenkins. I would appreciate any help or guidance here.  
Thank you!

---

<div class="post-metadata">

**Author:** ![Giovanni](https://avatars.discourse-cdn.com/v4/letter/g/7ea924/32.png) [@Giovanni](https://community.jenkins.io/u/Giovanni)\
**Post date:** [January 17, 2024, 9:23am UTC](https://community.jenkins.io/t/commit-pipeline-for-local-git-repo/11840/2 "2024-01-17T09:23:34Z")

</div>

In my opinion it is better to clone a repository from the pipeline instead of interacting with a local one. That said you can do pretty much what you want with the sh step, providing the user running Jenkins has access to the folder/file you want to access. A simple pipeline would be something like this:

```auto
pipeline {
    agent any

    stages {
        stage('My Stage') {
            steps {
				script {
					sh 'cd /to/my/path'
				}
            }
        }
    }
}

```

---

<div class="post-metadata">

**Author:** ![lipton](https://avatars.discourse-cdn.com/v4/letter/l/c67d28/32.png) [@lipton](https://community.jenkins.io/u/lipton)\
**Post date:** [January 18, 2024, 4:18am UTC](https://community.jenkins.io/t/commit-pipeline-for-local-git-repo/11840/3 "2024-01-18T04:18:32Z")

</div>

Thank you for your help here!  
I think I am following your point that whatever takes place in a Jenkins pipeline should be contained within Jenkins realm. I will follow this perspective.

I did adjust my sample pipeline to use git step command as you suggested, to clone the repository directly, and it worked actually, setting it up under /var/lib/jenkins/workspace. Still, this git command appears to be a canned sequence, granted, with some control parameters such as url, changelog, poll. However, if I want to run the sequence of ‘git clone’ and 'git checkout , I have to use sh command.

The usage of script mechanism is quite confusing. This mixture of Declarative and Scripted pipelines (which appears to be a subset of Groovy, if I am not mistaken) is quite convoluted. I hope it does not come as disrespectful to people who developed all that, certainly not intended as such. I really don’t see why script would be used, given that multiple sh commands are still needed. And still after a single sh is completed that shell session is over, e.g. the current directory reference is not retained.

I have worked quite extensively through the book “Continuous Delivery with Docker and Jenkins”. It has a lot of valuable information, however it does not cover all these details. For example, a git url: command is used, but what happens under the hood is not explained, just taken for granted. I was not able to find another book on Jenkins that was newer and more in-depth. And unfortunately the [jenkins.io](http://jenkins.io) documentation, while being well structured, does not explain a lot.

Pardon my seemingly excessive complaining, that’s not my intent, just trying to learn the tool and best practices for its usage.

Thank you
