Best practices and technical details

Foundry Branching is highly opinionated about the development style that organizations should implement. It features a monorepo hierarchy and enforces trunk-based development ↗ for fast, stable development.

Branches are intended to be short-lived and relatively small. This is because large branches are difficult to review and maintain, as resources become more prone to conflicts the longer they remain open.

Branching technical details

The following section includes details on how Foundry Branching works in different applications.

Foundry Branching repositories in Code Repositories

Foundry Branching for Code Repositories builds upon the existing Code Repositories branching implementation.

Foundry branching within Code Repositories.

Foundry Branching for data pipelines in Pipeline Builder

Foundry Branching for pipelines builds upon the existing data pipelines branching implementation.

Foundry branching within Pipeline Builder.

Foundry Branching for Ontologies

Foundry Branching for Ontologies builds upon the existing Ontology proposals implementation.

Foundry branching within Ontology Manager.

Foundry Branching for Workshop

Foundry Branching for Workshop enables you to modify Workshop modules and test changes on a branch. Unlike Pipeline Builder and Ontology Manager, Workshop does not have a branching mechanism other than Foundry Branching.

Foundry branching within Workshop.

Modify and test Workshop modules on a branch

With Foundry Branching, data that has been modified on a branch in Pipeline Builder can be previewed in Workshop on that same branch. Similarly, Actions can be run and changes to the Ontology can be tested in Workshop modules. To learn more about running Actions on branches, refer to the supported functionality documentation.

Running Actions on Foundry Branches
  • To run an Action on a branch, all object types modified by the Action need to be indexed on the branch.
  • Webhooks and email notifications are not executed when an Action is run on a branch.
  • If an Action type is backed by a function that is configured to make calls to external systems, it cannot be run on a branch.

Resolve conflicts

In some cases, the Workshop version on a branch can become out of date with the Main branch. This occurs when changes were made and merged to production after the creation of your Foundry branch. To resolve this, a rebasing feature will highlight where conflicts are occurring. Refer to Workshop rebasing and conflict resolution for more information.

Review and approve changes

Workshop integration with the Approvals application is still in development. This means that Workshop changes do not currently require a review process to merge your branch; changes made by users with Editor rights on the module are automatically approved.

Adding views to a branch

Views are not fully integrated into Foundry Branching, but can be added to a branch. To add a view on your branch:

  1. Build the dataset that backs the view on your branch via Code Repositories or Pipeline builder.
  2. On your view, use the Build dropdown in the top right corner to select Customize build....
  3. In the Data Lineage application, use the branch selector in the toolbar to select your branch name. Note that your branch name may appear slightly different in the branch selector, as spaces and underscores are not displayed.
  4. In the Manage builds section, build the view on your branch. You will need to enable the Force build on update-to-data resources option.

Once the build completes, the view will be accesible on your branch and can be used as a datasource to back entities in Ontology Manager. Note that the view will not be tracked as a changed resource on the branch.

Foundry Branching with restricted views [Experimental]

Support for restricted views in branching is in beta. To enable, contact your Palantir representative.