QA (public) » openQA Project (public)

Somehow I'm not sure whether #127949 will help with that. At least for Codecov (which has a better integration with GitHub) the cases where a token is needed are still problematic (because also then the token is not there when creating a PR from a fork). This just works because Codecov doesn't require a token for public projects¹. Maybe we should provide an openQA instance that does not require a token (or in our case API credentials) as well? Or provide some limited public access on an existing instance just for that?

¹ It currently kind of does but that's considered a bug, see #128129.

If it was possible to make use of the API credentials from any fork then anybody could spawn any kind of openQA job on o3. If that is acceptable we might as well allow anybody to spawn any kind of openQA job on o3 without providing API credentials. This way we'd avoid the problem of making the credentials available to forked repos.

Supposedly this kind of access is nothing we should introduce by default. We could add an openQA setting to allow anonymous job posting and enable it only on o3.

However, o3 is also where a lot of production workload is executed. Maybe we don't want to mix that with this kind of development workload. We could setup a 2nd public instance for this.

mkittler wrote:

If it was possible to make use of the API credentials from any fork then anybody could spawn any kind of openQA job on o3.

Well, for unknown contributors openQA still asks the target repo owners for approval to run CI jobs. So whatever is working for GHA and OBS build checks we should still be able to do with openQA. How does it work for OBS build checks?

Well, for unknown contributors openQA still asks the target …

You mean GitHub still asks … ?

How does it work for OBS build checks?

Good question. After a brief look I'd say it works for OBS because it uses a web hook. So GitHub itself (and not some possibly user-defined code running within a CI runner) makes an HTTP request to OBS using some secret stored in the repo config. Then OBS reacts to it. I suppose we could replace OBS with openQA. So we needed to implement a route handling the web hook on the openQA side. This would basically mean we'd implement #127949 first it (unlike I suspected before) it would help us with this. So maybe raise the prio of that ticket to be at least the as high as the prio of this one?

Considering the approach we've taking with #128129 we could also do the same here. So we'd make the "token" public. I suppose that would mean adding a new admin level in openQA so one can have an API key/secret that only allows posting an ISO and also only with constrained parameters (like _GROUP=0 and BUILD and TEST would automatically get some prefix/appendix so these jobs would never interfere with normal dashboards). We might also want to disallow the download feature (although it is likely not problematic because it uses a whitelist anyways).

mkittler wrote:

Considering the approach we've taking with #128129 we could also do the same here. So we'd make the "token" public. I suppose that would mean adding a new admin level in openQA so one can have an API key/secret that only allows posting an ISO and also only with constrained parameters (like _GROUP=0 and BUILD and TEST would automatically get some prefix/appendix so these jobs would never interfere with normal dashboards).

But then anyone with the token could DoS us by triggering endless number of tests, right?

Yes - so it is definitely not ideal and I prefer to continue with #127949. This one actually also allows one to flood an openQA instance with tons of jobs. One just has to push a scenario definitions YAML file that generates tons of jobs. I suppose we want to limit this before actually configuring the webhook on a production instance. However, limiting this shouldn't be a big deal.

I've been working on this today and I've just updated #127949#note-10. The pending PR: https://github.com/os-autoinst/openQA/pull/5133 (I'm using this comment because then there's only one place for what's left TODO.)

When at least the cleanup has been concluded we can consider this good enough for resolving this ticket here and create follow-up tickets for the remaining improvements.

I've added the webhook for o3 on https://github.com/os-autoinst/os-autoinst-distri-example/pull/22 and it works. It is using the openQA user "webhooks" with its own key/secret pair.