action #67810


trigger OBS builds of openQA github pull requests

Added by okurz about 4 years ago. Updated almost 4 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:



Test OBS package builds and tests before merging pull requests


Previously we had each github pull request trigger OBS builds of the corresponding fork and branch based on an undocumented solution configured by coolo but nobody else knows how it was done. Probably based on running on a custom instance somewhere. This broke sometime around 2020-05 to 2020-06 . We should repair this, bring it up properly and at best cover os-autoinst as well.

Further details

Maybe just follow ?


obs-action-success.png (15.1 KB) obs-action-success.png Screenshot Status Success tinita, 2020-06-15 16:36
Actions #1

Updated by okurz about 4 years ago

  • Description updated (diff)
Actions #2

Updated by tinita about 4 years ago

Dan Cermak suggested to write a GitHub Action using

Actions #3

Updated by tinita about 4 years ago

Actions #4

Updated by tinita about 4 years ago

And here is the related Github issue:

Actions #5

Updated by tinita about 4 years ago

A first version is ready to test:

Here is a Proof of Concept for os-autoinst:

Attached a screenshot

Actions #6

Updated by livdywan almost 4 years ago

@tinita Are you still looking into this?

Actions #7

Updated by okurz almost 4 years ago

  • Status changed from New to Feedback
  • Assignee changed from okurz to tinita
  • Target version set to Ready

coolo enabled the old approach again after fixing problems after the account originally used was migrated using IDP. So we have good checks back which is making any other solution still helpful but with lower priority.

@tinita would be cool if you can provide your last status in written here

Actions #8

Updated by tinita almost 4 years ago

I think it would be not that useful due to the way Github Actions secrets are working.

One disadvantage is that people pushing to their own fork have to create login secrets for OBS.
Then it is working.

BUT as soon as they make PR, the build is running in the context of the original repo, and then it doesn't use a secret at all. Of course the origin secrets cannot be used for security, but also the secrets of the fork aren't used in that case.

So it's only useful to explicitly check if a feature branch builds correctly, either in a fork or the origin. But for a PR it's useless (one could link to the build of the fork though).

Actions #9

Updated by okurz almost 4 years ago

  • Status changed from Feedback to Resolved

alright. So something learned :) I guess we can live with the current situation for now. Any next time when the existing service stops working again we could just start the pull request builder elsewhere.


Also available in: Atom PDF