Overview
Tulip allows you to leverage your git provider by automatically attaching a pull request to deployment records. These pull requests capture all of the planned configuration changes in Tulip deployments and allow you to:
Comment, discuss and get approval from colleagues about the planned configuration changes
Connect your preferred CI/CD tool in order to automate validations and deployments. You can further integrate any other external tool for additional use cases, e.g. static code analysis tools.
Push and deploy additional edits to your security application configurations, made outside of the Tulip Platform
Enabling deployment pull requests
Tulip can be configured to automatically create a pull request for any deployment record targeting a certain app connection.
In order to enable this behavior, you will first need to connect your app connection to a git repository and branch and make sure to turn on 'Deployment protection via Tulip PRs'.
If your environment is already connected to a git branch, deployment protection via Tulip PRs can be turned on via the version control section of the app connection settings screen.
Deployment Pull Request LifeCircle
When deployment pull requests are enabled for an app connection, Tulip automatically creates a feature branch from the app connection branch for any new deployment reaching the "deployments preview" state, commits the planned configuration changes, and opens a pull request to merge into the app connection branch.
Any updates to the deployment preview (e.g., element selection changes or edits) are pushed to the feature branch, keeping the pull request aligned with the planned configuration changes.
The deploy operation in Tulip remains disabled until the pull request is mergeable, based on the repository’s branch protection rules.
Learn more about enabling branch protection rules for your Git providerOnce the deployment is completed, Tulip automatically squashes and merges the pull request, ensuring the app connection branch reflects the deployed configuration. Please make sure not to push or merge PRs to the app connection branch outside of Tulip.
Feature Branches Naming Conventions
In Tulip, deployment feature branches follow a specific naming convention: tulip/env/<envId>/deployment/<deploymentId>.
This pattern is critical because automations tied to Tulip deployments are triggered when pull requests (PRs) are created or updated, but only for feature branch names starting with tulip/env.
This ensures that only deployment-related actions activate these automations. PRs involving other types of changes should avoid this naming structure, as it’s reserved exclusively for deployments and not general modifications.
For more information, check out these resources:
Deploying additional edits using Pull Requests
Users can also use the created pull request to make additional edits to the deployed elements or support a classic "Find and Replace" use case. This can be used to perform advanced editing on your files - for example, replacing a value in many files, or introducing a large amount of new elements created by some internal script.
To include external edits in your Tulip deployment:
Clone the git repository to some local repo
Checkout source branch of the pull request
Perform your edits
Commit and push these edits to your remote repo
Tulip will automatically detect incoming changes, and will ask the deployer to pull these commits into the deployment.
When committing additional changes to Pull Requests, avoid force-pushing your commits as that may prevent Tulip from pulling these changes properly.