Common Pitfalls to Avoid in the Continuous Integration with OBS and GitHub/GitLab
Many of you are already playing around with our new beta feature: Source Code Management (SCM) system integration with OBS. You might have faced some errors during this time.
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.
Here you can find a list of the most common pitfalls you can face and how to solve them.
Error message: “You are not authorized to create this Token/workflow.”
This SCM integration feature is only available for users in the beta program. Please join the beta program in OBS to be able to use this new feature.
Non-existent YAML Configuration File
Error message: “.obs/workflows.yml could not be downloaded on the SCM branch
The feature requires that your SCM repository contains a
.obs/workflows.yml file. OBS only considers this file in your default branch (i.e master or main) and will not consider this file in other branches or forks.
Make sure you place the configuration file in the default branch before you set up your webhooks.
Invalid YAML Configuration File
Error message: “Invalid workflow step definition”, “Unsupported filters” or “Filters
YAML Checker can help you too.
Invalid SCM Token
Error message: “Bad credentials”.
If the SCM token is not correct you’ll receive this error. To resolve this you can create a new OBS workflow token with valid SCM token and delete the existing one.
osc token -d <token_id> can be used to delete the token and Check sections 1 and 2 of Continuous Integration with OBS and GitHub/GitLab for more details.
Non-existent Project or Package
Error message: “Project not found
In the configuration file
.obs/workflows.yml, you have to specify the name of the project and package you want to connect with the SCM.
Make sure the project and package really exist in OBS before you set up the webhook.
Missing or Invalid
The OBS package you are going to use in the integration should contain a
_service file pointing to the right SCM repository and branch, as it’s described
in the Use the SCM Sources in Your OBS package section of a previous blog post. If the
_service file is not setup correctly
the package will still be able to build but it will not contain the latest changes from your target branch.
You can check a sample of
_service file published on OBS.
No Build Result Updates Are Displayed in Your PR/MR
If somehow a package can’t be build, then the status of the check in your pull/merge request will never change. Some of the more frequent causes of packages not building are:
- A build is unresolvable
- A build is broken
- No repositories defined on your source project You should check the project directly on OBS and help each other with problems.
Where to See the Errors?
Some errors you will also see in your pull/merge request or in OBS itself. Once you set the webhooks, you can detect the errors returned by OBS in the webhook response.
In GitHub, you can find them in: Settings -> Webhooks -> Edit webhook -> Recent Deliveries (tab)
In GitLab, you can find them under: Project -> Settings -> Webhooks -> Edit -> Recent Deliveries (at the bottom of the page).