More Flexibility for Workflows in the OBS and SCM Integration

Right in time for the holiday season, we have prepared you a gift for the continuous integration between OBS and SCMs. We are introducing placeholder variables and for your workflows configuration files, a customizable location. Let’s see how this new flexibility helps you in your work.

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.

Placeholder Variables

Whenever a webhook event comes in, OBS downloads the workflows configuration file and parses it. This was previously static, but you can now use placeholder variables to tell OBS to replace them with data from the webhook event payload.

As of this writing, four placeholder variables are supported. Below is a workflows configuration file example with the %{SCM_REPOSITORY_NAME} placeholder variable:

# The test_build workflow will branch a package based on the SCM repository name from which the webhook event came from.
test_build:
  steps:
    - branch_package:
        source_project: hello_world
        source_package: %{SCM_REPOSITORY_NAME}
        target_project: hello_world:CI
  filters:
    event: pull_request

We are sure you will come up with a lot of interesting ways to use this. For more details on this feature, we invite you to read the user documentation.

A New Path

By default, OBS expects your workflows configuration file to be at .obs/workflows.yml within your SCM repository. For any reason, you might want to store this file somewhere else and this is completely fine. This is now possible and it’s as simple as editing your token in the web UI. Here’s an example of a workflow token for which OBS now expects the workflow configuration file to be at ci/my_workflows.yml:

This is customizable on every workflow token, so two tokens could have a different path for the workflows configuration file.

Another Location For Your Workflows Configuration File

Having your workflows configuration file in each one of your SCM repositories might be good enough for you, perhaps they are all different in their own ways and this is perfectly acceptable if it fits your needs.

Sometimes, this is however resulting in a lot of duplication and maintenance work for you. Avoid all of this by setting, for your workflow tokens, an URL where OBS should download the workflows configuration file. As long as OBS can reach this URL, you are free to store your workflows configuration file wherever you like. It could be a SCM repository where you already store global configuration files, a S3 bucket on AWS, a Gist on GitHub, anything… you choose.

This URL can be individually configured per workflow token in the web UI.

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.