Dear community , We have been using struggling in implementing snaplogic and github integration using Jenkins getting a lot of issues while doing github. Please share us your experiance in implementing and also if there is a fix please share us
Hi Paul, are you using GitHub.com, or an on-premises GitHub Enterprise installation? To better assist, it would be helpful to understand your environment in more detail, as well as the specific issues you’re encountering.
Hi Ingo, We use Github.com and we have Jenkins to handle the CI-CD using snaplogic public Rest api to deploy the pipeline from github to snaplogic while we use the git pull through public API we are fine with behaviour for the assets with git status Added removed tracked and untracked. But the issue we find is that with Tracked,Conflict Tracked, Modified Locally Tracked Remotely Statuses. Where we were not able to have control on the behaviour
we would be glad if we get your assistance in resolving this
Can you elaborate on what the issues are? It sounds like as if you have multiple people pushing to the same GitHub branch and the work they do conflicts with each other. Could that be the case?
Hey Paul, There are several strategies you can follow. SnapLogic recommends a trunk-based development approach, but you can also choose another strategy if it fits your team and workflow better. You can find more details here: https://docs.snaplogic.com/cicd/git-integration/repo-track.html Regarding this: Tracked,Conflict Tracked, Modified Locally Tracked Remotely Statuses, please share what exactly you see as a problem? For example, Modified locally and tracked assets can be ready for a commit. After you perform a commit, you can see the pipeline changes in Github. Hope this helps.
Hi Slavko, Thanks for the information and for sharing the SnapLogic documentation. At the moment, our organization’s Git strategy doesn’t allow us to follow a trunk-based development approach. Our current setup is structured as follows:
Each SnapLogic Project Space maps to a single source repository in GitHub for a given source/target combination.
Within that repository, each project or application is organized into its own separate folder.
We may have multiple developers working concurrently on different projects within the same repository.
Given this model, we’re trying to understand how best to manage the following statuses in SnapLogic:
Conflict Tracked
Modified Locally
Tracked Remotely
Our main concern is around parallel development. For example, if multiple developers are working in different project folders but within the same repository, how does SnapLogic recommend handling asset tracking and commits to avoid conflicts or unintended overwrites? In particular:
How should we manage “Modified Locally” assets when multiple developers are committing to the same repository?
What is the recommended approach when assets appear as “Conflict Tracked” in this multi-project, multi-developer setup?
Are there best practices for aligning SnapLogic asset tracking with a non–trunk-based branching strategy (e.g., feature branches or environment-specific branches)?
We want to ensure our Git workflow remains consistent with our organization’s standards while still leveraging SnapLogic’s Git integration effectively. Appreciate your guidance on how best to align these approaches.
Using the current strategy may be a bit challenging, but it shouldn’t cause major problems. In practice, conflicts are unlikely because developers are working in different project folders and not on the same pipeline. Even if multiple people are committing changes, each commit will simply reflect the current state of that specific pipeline. Conflicts usually happen only when two developers modify the same pipeline at the same time. Since you’re not using trunk-based development and are working within a single branch, that situation is less likely to occur.
Hi Slavko, Good day. Nice to meet you. I’m from Paul’s team. We need your help with a Git pull issue using REST API (cURL). We use Git as our repository and Jenkins for CI/CD with the project space checkout mechanism (single repo with multiple integrations). Sometimes we make manual changes in the SnapLogic UI. During the next deployment, when Jenkins runs the Git pull, the locally tracked/modified changes are not getting overwritten as expected. We want this to be handled fully programmatically without any manual steps. I can share the Jenkins Groovy code if needed for review.
Hi Vineeth, nice to meet you as well! I also thought this wasn’t normal behavior, but it looks like SnapLogic is actually protecting us from overriding work that hasn’t been committed yet. What I would suggest is creating another project space that will serve as your “release” , where you only perform Git pulls, and don't do any changes through the UI. Then you can continue working in the first project space, developing, making changes, and committing them to the branch. Hope this helps.
Hi Slavko, Thanks again for your guidance. Let me clarify our Production scenario a bit more clearly. In our setup: Only the pipelines are promoted to Production from Git.
(Sometimes)The Tasks are created directly in Production (they are not version-controlled in Git) .
Developers do not have access to Production — deployments are handled via Jenkins using the SnapLogic Public REST APIs.
However, in Production, there are cases where:
We make minor emergency changes directly in the SnapLogic UI to stabilize a running job.
Some scheduled pipelines use watermark/timestamp files stored in SLDB, and there have been cases where we updated the file path or file configuration inside a File Reader Snap directly in Production.
These changes are not committed back to the Git repository.
Later, when we deploy a subsequent release of the same repository to Production:
Jenkins performs a Git pull via the API.
SnapLogic detects “Modified Locally” or “Conflict Tracked” assets.
The Git pull does not overwrite the local changes automatically.
The deployment does not fully align with the repository state because SnapLogic protects those uncommitted changes.
From SnapLogic’s perspective, this protection makes sense. However, from our CI/CD standpoint:
Production should always reflect the Git repository as the single source of truth.
No manual UI changes should block or interfere with deployment.
We need the deployment to be fully automated, without requiring manual cleanup of locally modified assets.
So our key question is: Is there a supported way to force a Git pull to override local changes programmatically (similar to a hard reset), ensuring Production always syncs exactly with the repository state? Or is the only recommended and supported approach to strictly prohibit any UI-level changes in Production and maintain a separate release-only Project Space? We want to align with SnapLogic best practices while keeping our CI/CD process fully automated and controlled. Appreciate your guidance.
