Clear Separation Between Incoming Webhooks and Status Reports for the SCM/CI Integration

Another round of SCM/CI integration. This time we focused on a better separation between the incoming webhooks and the status reports we send back to the SCM for the individual workflow runs. On top of this we made the error messages more meaningful, in case something goes wrong when reporting back to the SCM.

Haven’t you tried the SCM/CI integration yet? Please join the beta program and read our previous blog posts to learn about the topic.

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.

This feature is documented in the SCM/CI Workflow Integration chapter of the OBS User Guide.

Incoming Webhook or Outgoing Status Report?

Previously it was hard to tell where the data we show for the workflow runs is coming from. Is the request/response coming from the webhook produced by the SCM or is this something we’ve produced and sent back? We worked on a clear separation between those two cases. From now on we show two tabs, one for the data received through the incoming webhook from the SCM and one for the status reports we send back.

SCM status reports tab
SCM status reports tab

Improved Error Messages for SCM Status Reports

Besides the improved separation, we also worked on the error message we produce when something goes wrong while reporting back the status to the SCM. This will help you to debug common issues, like an expired token, insufficient permissions or network problems.

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.