Support for Push Events, a Rebuild Step and More for the SCM Integration

by the OBS Team posted on 28th Sep 2021

We again moved forward with the integration of source code management systems (SCM) in the Open Build Service. This time with a new rebuild step, support for push events, and filter for branches and events. Some of the new features introduce breaking changes for existing workflows. So keep reading if you want to know how to adapt your existing workflows and how to use the new features.

If you haven’t already, join the beta program to start integrating OBS with SCMs.

We started off the continuous integration between OBS and GitHub/GitLab in May 2021, then made some improvements in June 2021. We introduced advanced features like reporting filters and support for self-hosted SCM together with a list of common pitfalls in July 2021 and in August 2021, we continued with two new steps and a UI for tokens. In September 2021, we supported more actions for pull/merge requests, improved the UI for tokens, and added support for push events and a rebuild step. In November 2021, we presented the user documentation and further improvements for the UI for tokens and workflow runs and more. We worked on UI and reporting improvements in February 2022, followed by a step to trigger services and the improvement of the error messages in April 2022. Afterwards, we clarified the separation between incoming webhooks and status reports in May 2022, then sharing tokens was made possible in June 2022. Later in July 2022, we added support for the SCM Bridge feature. Around September 2022, the feature was considered stable, so we enabled it for all the OBS users, but that wasn’t the end; later in September we reached the milestone of supporting Gitea on top of GitHub and GitLab. In December 2022 we introduced placeholder variables in addition to a customizable configuration file location. Later on we brought notifications for failed workflow runs, and now we introduced a new way of listing the events by multiple filter parameters

This feature is documented in the SCM/CI Workflow Integration chapter of the OBS User Guide.

Select the Target Project for Your Steps (Breaking Change)

The target project for the currently supported steps used to default to the home project of the corresponding token user. From now on, you must set the target project yourself by adding the target_project key to all branch_package and link_package steps.

workflow:
  steps:
    - link_package:
        source_project: games
        source_package: ctris
        target_project: home:obs_user

Renamed the Source Project Key for the Configure Repository Step (Breaking Change)

Not a new feature, but still worth to mention. We renamed the source_project key in the configure repository step to simply project. This is just for the sake of clarity. Make sure to adapt existing workflow configuration files.

workflow:
  steps:
    - configure_repositories:
        project: OBS:Server:Unstable:CI
        repositories:
          - name: openSUSE_Tumbleweed
            target_project: openSUSE:Factory
            target_repository: snapshot
            architectures:
              - x86_64
              - i586
          - name: openSUSE_Leap_15.2
            target_project: openSUSE:Leap:15.2
            target_repository: standard
            architectures:
              - x86_64

Run Multiple Workflows

Defining multiple workflows in the .obs/workflows.yml configuration was already possible in the past, but we can now confirm that this is working and we are considering this for future adaptions. One thing worth to mention is that every workflow needs a unique name in order to be processed.

first_workflow:
  steps:
    - branch_package:
        source_project: test-project
        source_package: test-package
        target_project: test-target-project

second_workflow:
  steps:
    - branch_package:
        source_project: another-project
        source_package: another-package
        target_project: another-target-project

Support for Push Events and Event Filters

So far, it was only possible to run the workflows for pull/merge requests in GitHub and GitLab. With the new event filter section, we also start to support push events. This enables you to run workflows if you, for example, push directly to a development branch in your repository or on the latest commit merged into the main branch. For now, you can choose between the pull_request and the push events.

workflow:
  steps:
    - branch_package:
        source_project: games
        source_package: ctris
        target_project: home:jane_doe
  filters:
    event: push

Run Workflows Only on Selected Branches

Especially after adding support for the push events, it might be interesting for some of you to run workflows only for certain branches. It is now possible to ignore or select certain branches in the filters section. As with the other filters only has precedence over ignore if both are set.

workflow:
  steps:
    - branch_package:
        source_project: games
        source_package: ctris
        target_project: home:jane_doe
  filters:
    event: push
    branches:
      only:
        - main
        - staging
      ignore:
        - development

Trigger Rebuilds of Packages in Workflows

Last but not least, there is a new rebuild step for the workflows. It makes it possible to trigger the rebuild of a selected package inside the OBS. One use case for this could be to trigger the rebuild of a package after a new commit got pushed to the main branch.

workflow:
  steps:
    - rebuild_package:
        project: home:Admin
        package: ctris

How To Give Us Feedback

There are two ways to reach us:

Please note that we favor GitHub to gather feedback as it allows us to easily keep track of the discussions.