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.

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.
Workflow runs show view
Workflow runs show view
  • New filter options to help filter Workflow Runs based on status and event type
Workflow runs filters
Workflow runs filters

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.

Workflow run artifacts
Workflow run artifacts for a push event

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.