UI and Reporting Improvements for the Continuous Integration with OBS and GitHub/GitLab

Today, we have some improvements around the continuous integration we unveiled in one of our previous blog posts. We expanded the workflow run interface, added a new type of step to configure repository flags, and introduced a breaking change to the configure_repositories step.

As you know, this is a beta feature. So, do not forget this feature is under the beta program. Join!

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.

Support multiple repository paths for the configure_repositories step

You already know about the configure_repositories step. Until now a single path element is defined per repository configured, but we realized for some projects more than one path has to be defined. So, we have made improvements for the support of multiple path elements. The breaking change has been documented and you can check it out here.

The set_flags step

Projects and packages can have different flags based on repositories and architectures. With the set_flags step, you have the opportunity to manage flags for your projects and packages. There are OBS-wide defaults for each flag type. This step is only necessary if you want to diverge from those defaults.

Here is a simple example of how you can use it:

workflow:
  steps:
    - set_flags:
        flags:
          - type: build
            status: enable
            project: home:Admin
          - type: publish
            status: disable
            project: home:Admin

Please refer to the documentation to learn more.

Improvement for Workflow Runs User Interface

The Workflow Runs page is the most important place to debug your workflows. It helps you to detect the problems like the wrong configurations in workflows.yml. So to make it easier to debug and troubleshoot broken SCM integrations we have added some more features to the Workflow Runs UI:

• The details about each workflow run are displayed on a new page.
• Together with the Request and Response, we added the new tab Artifacts.

• New filter options to help filter Workflow Runs based on status and event type

Artifacts of Workflow Runs

A single webhook on your SCM can trigger different workflows, given in .obs/workflows.yml, to run. Each Workflow Run will most likely generate some changes inside the OBS projects or packages. Those changes are what we call Workflow Run Artifacts. For example, repositories are created if the step is configure_repositories or projects and packages are created in steps like link_package, etc. After each workflow run, we now display all the artifacts involved so you can better understand and debug what was going on.

How To Give Us Feedback

There are two ways to reach us:

• On GitHub, by opening an issue and / or commenting on an already opened issue.
• On IRC, by talking directly to us. We are in the channel #opensuse-buildservice on Libera.Chat.

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