SCM/CI Workflow Runs and More

We go further with the SCM/CI workflow integration in OBS. You, beta testers, had difficulties in understanding why your integration failed when something did not go as planned. This is solved with the new workflow runs UI feature, with detailed information about every workflow that ran once you triggered a workflow token. Keep reading for more details.

Do not forget this feature is under the 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.

Tokens Web UI

At this point, you might be familiar with the tokens web UI. After a few improvements, it looks like follows.

The token id is now visible from the list of tokens and we have introduced a new link to the workflow runs .

Workflow Runs

You created your workflow token in OBS and prepared the project you wanted to work with. You also defined the configuration file, .obs/workflows.yml, and set up everything on the SCM side. However, you did not get the result you expected. Something was wrong but you had no clue why. That was a common scenario when integrating an SCM and OBS to run some workflows for the first time. But we have good news for you!

From now on, every time a workflow token is triggered, OBS will track information about each workflow run.

You will get details like:

• the start time and the status of the workflow run (running/fail/success) represented by icons;

• the request headers and the payload received from the SCM;

• the response body sent from OBS to the SCM, containing the error messages in case of a failed run.

Although this tool will be of great help to you, we recommend that you follow the instructions thoroughly for successful integration.

Push Events for Tags

Our workflows now accept push events for tags. You could, for example, run a certain workflow only when a tag is pushed to a repository rather than on every push to a branch.

You can filter by this type of event as shown in the following example. Read more here.

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

For the branch package and link package steps, the package created by those steps will contain the name of the tag which triggered the webhook event.

Refer to the documentation about the steps for details on this.

To ensure this is correctly working, you need to modify your webhook on GitLab to trigger “Tag push events” if this isn’t already done. For GitHub, you need nothing apart from “Pushes”.

And Much More

Apart from the big changes in the web UI, we continue improving other areas. We now handle other possible errors and display a more readable version of the text in the SCM checks by using the short version of commit SHAs for push events.

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.