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.
