Skip to content

Work Flow and Branching Model

Jump to bottom
Jimena Salas Alfaro edited this page Feb 22, 2022 · 1 revision

Work Flow and Branching Model

This wiki provides a guide to properly use Meta-RidgeRun repository to integrate changes into the public and private projects recipes. Meta-RidgeRun layer's main goal is to provide customers the support to integrate our RidgeRun products into their Yocto builds easily.

In order to keep the repository cleaned and up-to-date with the Yocto releases, a GitHub Workflow has been designed. This workflow tries to be on sync with the Yocto workflow and releases methodology. For that reason below you can find the branching name and branching specification:

  • master: This branch will keep the support for the current unstable Yocto version
  • yocto-<yocto-version>: These branches will keep the support for all the stable Yocto versions

Whenever a release becomes stable and a new unstable Yocto version is released, a yocto-<yocto-version> is created from the stable release, and master branch starts adding support to the new unstable version. For example, by the time this wiki page was created, the stable version is Sumo and the under development/unstable release is Thud, so that there is a yocto-sumo branch keeping all the support for Sumo, while master branch keeps the on-going support for Thud. Once a new Yocto version appears and Thud becomes stable, a new branch from master will be created, named yocto-thud and master will start with the support for the new release.

This branching model helps having control over each Yocto release, and all the changes it involves on the RidgeRun products recipes and layer.

The idea of this branching model is to keep supporting old releases while Yocto evolves, and to avoid losing track of the changes required to get all the recipes working on an specific Yocto version.

Adding a new recipe

If the new recipe will be added to an old release please follow the usual workflow:

  • Create a feature branch from the yocto release where the recipe will be added
  • Add your recipe to the new feature branch
  • Ask for code review
  • Merge the branch back into the corresponding release branch
  • Delete your feature branch after merge

After this, make sure to include your recipe in the master branch as well following the same procedure described above. If the recipe needs to be added to the master branch only this doesn't have to be replicated to the old release branches.

NOTE: All new recipes must go through pull request!

Integrating changes on Public Projects

In case of RidgeRun Open Source Projects, maintainers should be able to keep updating the recipes to the latest versions, and keep testing their functionality in all the supported Yocto Versions.

Integrating changes on Private Projects

In case of RidgeRun Products such as GstWebRTC, GstQtOverlay, etc, the Yocto recipes uses Gitlab deliveries, so for each delivery it requires to change following fields on the recipe:

  • SRCBRANCH
  • SRCREV_base
  • SRCREV_common
  • SRC_URI = ... git://[email protected]/RidgeRun/orders//gst-webrtc.git;protocol=ssh;branch=${SRCBRANCH};name=base...
Clone this wiki locally