For AI agents: the complete documentation index is available at https://docs.dataplatform.ovh.net/llms.txt, the full documentation bundle is available at https://docs.dataplatform.ovh.net/llms-full.txt, and this page is available as Markdown at https://docs.dataplatform.ovh.net/tutorials-versioning-basics.md.
  • 🇬🇧 English
  • Learn versioning and repositories basics

    This tutorial demonstrates how to use the Platform's native versioning system or how to setup a Git repository to track the changes in your Data

    Objective

    This tutorial demonstrates how to use the Platform's native versioning system or how to setup a Git repository to track the changes in your Data Processing Actions.

    Introduction

    Requirements

    To follow this tutorial, you need to be familiar with the Data Processing Engine and you should preferably have done the Getting Started guide. The essential is that you know what Actions are for and how to use them.

    Concepts overview

    Editing actions is always on autosave mode. When you are trying to iterate on existing actions, it is recommended to create several versions of the actions' code. This lets you incrementally introduce variations to experiment and test your work, while keeping the version in production always intact.

    On the Platform, this versioning happens at the level of the repositories. The repositories are the tabs you see at the top of the Actions' tree view.

    repos

    You cannot version an individual action, but rather a whole repository of actions. The versioning panel can be accessed at the top right of the repository header:

    Concepts overview — Versioning panel

    There are 2 versioning systems on the Platform:

    Now let's see how all of this works in practice!

    Use the Platform version control system

    By default, each repository of actions on the platform has an integrated version control system which allows you to manually manage the different versions of the code (i.e. actions) they contain.

    Repositories all have:

    • a deployed version, which is the version served when executing the job.
    • an editing version, which is the version currently being edited through the editor panel.
    Info

    If your repository only has one version, the active version is the same as the deployed version, which means that you are editing your actions in production.

    If your repository has two versions or more, the deployed version cannot be edited. It can be viewed in read-only mode.

    Versions need to be created manually. To create a new version for the repository, open the versioning panel at the top right and click on the + icon.

    Use the Platform version control system — Versioning fp1

    Choose which version to duplicate to create the new version.

    Use the Platform version control system — Versioning fp2

    After creating the new version, the deployed version will not change. You are able to edit the new version directly.

    Use the Platform version control system — Versioning fp3

    Click on the Play button to set a new version as the deployed version: the version of the code used when actions of the repo are executed.

    Use the Platform version control system — Versioning fp4

    Use a repository linked to Git

    Each repository can be linked to an external Git repository in which case versions are synced with Git commits. This allows you to update & test actions continuously without affecting the version deployed in production.

    Linking a repository to Git

    To link your repository on the platform to Git, you must click on the gear icon to edit an existing repository or create a new a one. Either of this actions will open the repository configuration window.

    img1

    Click on Connect to Git to expand the window.

    img1

    Here the first thing you need to enter is the Repository SSH URL.

    It is generally found on repository cloning options of common Git solutions. On GitHUB, for instance, it can be found on Code > Clone > SSH.

    github

    Next click on FETCH to get the distant branches and select the branch you desire to use.

    Finally, copy the Public SSH key given at the bottom and paste it in the list of SSH keys associated to your account on your Git solution. For GitHUB, you can follow this tutorial.

    Committing and pushing

    After changing an object in a repo, your repo will display the uncommitted changes as shown in the image below. You can commit and push them by clicking on the arrow pointing upwards indicated in the image.

    commit
    Info

    If there is a conflict when you push, your changes will not be pushed to the branch you configured, instead they will be pushed to a new branch with same name of the current branch and a suffix of _conflictN, where N is the number of the conflict. For example, if your branch is named current-branch and your push causes a conflict, the new branch will be named current-branch_conflict1. If there is a conflict again when you push, the new branch will be named current-branch_conflict2.

    Pulling and merging

    Pull distant changes by clicking on the arrow pointing downwards indicated in the image, a popup window will prompt you to confirm your decision. All uncommitted changes will be lost and both branches will be merged together.

    pull

    Go further

    If you need training or technical assistance to implement our solutions, contact your sales representative or click on this link to get a quote and ask our Professional Services experts for a custom analysis of your project.

    Ask questions, give your feedback and interact directly with the team building the Data Platform on the dedicated Discord channel.

    If you need support with your OVHcloud services, create a request in our Help Centre.

    Join our community of users.