Support for Push Events, a Rebuild Step and More for the SCM Integration
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. And now, we bring notifications for failed workflow runs.
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
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.
- name: openSUSE_Tumbleweed
- name: openSUSE_Leap_15.2
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.
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
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
only has precedence over
ignore if both are set.
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.
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
Please note that we favor GitHub to gather feedback as it allows us to easily keep track of the discussions.