Project

General

Profile

action #87698

coordination #58184: [saga][epic][use case] full version control awareness within openQA, e.g. user forks and branches, fully versioned test schedules and configuration settings

action #48641: [epic] Trigger openQA tests in pull requests of any product github pull request

action #86063: [epic] Add possibility to trigger openQA API calls, e.g. single "jobs", without the need of the client / over the webUI / with curl

openQA jobs can be triggered with single curl calls

Added by okurz 5 months ago. Updated 2 months ago.

Status:
Resolved
Priority:
Low
Assignee:
Category:
Feature requests
Target version:
Start date:
2021-01-13
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

Motivation

See parent epic #86063

Acceptance criteria

  • AC1: openQA jobs can be triggered with single curl calls
  • AC2: non-operator users are prevented from triggering jobs or do not even see the functionality

Suggestions

  • e.g. a POST route where one can authenticate with username+password forwarded to any external authentication service or existing API key+secret.

Related issues

Copied to openQA Project - action #90788: openQA jobs with arbitrary parameters can be triggered over the webUI for authenticated users with right permissions (operator+)Workable

History

#1 Updated by kraih 5 months ago

  • Assignee set to kraih

I can take a look at this. AC1 could use some clarification though. Do we want a workflow with pre-negotiated authentication tokens (stored in the database, think GitHub personal access tokens), or a workflow where an expiring token can be requested via the API itself (since it expires, most curl operations would require at least two HTTP requests, one to authenticate and another to actually perform the API operation, not to mention browser requirements for external authentication methods like OpenID)?

#2 Updated by kraih 5 months ago

Personally, i always liked the simplicity of GitHub personal access tokens. It makes using curl for API access very comfortable. But of course there's a security risk with tokens that require the user to press a delete button and that never expire on their own.

#3 Updated by cdywan 5 months ago

kraih wrote:

Personally, i always liked the simplicity of GitHub personal access tokens. It makes using curl for API access very comfortable. But of course there's a security risk with tokens that require the user to press a delete button and that never expire on their own.

We could probably still decide to revoke tokens at an expiry date if we want to. But it's worth considering that expiry of API keys for openQA is already optional... maybe we should just get rid of that?

And GitHub allows you to define the permissions granted when using the token. So you could for example allow jobs to be cloned but nothing else.

#4 Updated by okurz 5 months ago

We already have expiration on API keys+secrets. Can we just use the already existing keys+secrets?

#5 Updated by kraih 4 months ago

  • Status changed from Workable to In Progress

okurz wrote:

We already have expiration on API keys+secrets. Can we just use the already existing keys+secrets?

We can, and for starters i'll make a version that works like curl -u kraih:KEY:SECRET https://openqa.opensuse.org/....

#6 Updated by okurz 4 months ago

looks good :+1:

#7 Updated by kraih 4 months ago

The main feature was merged. https://github.com/os-autoinst/openQA/pull/3757 But i do still want to add documentation and clean up the whole authentication code a little (as was suggested by reviewers).

#8 Updated by kraih 3 months ago

  • Status changed from In Progress to Feedback

Cleanups and documentation are done.

#9 Updated by okurz 3 months ago

I tried curl -u okurz:$key:$secret -X POST https://openqa.opensuse.org/api/v1/jobs/1661550/restart now and I got "{"error":"invalid personal access token"}". Can you help?

#10 Updated by okurz 3 months ago

  • Status changed from Feedback to In Progress

kraih found the problem and will create a PR. o3 is hotpatched and I can confirm that the above works as expected.

#11 Updated by kraih 3 months ago

Opened a PR with the fix. https://github.com/os-autoinst/openQA/pull/3774

Problem was that my local and staging machine tests did not involve users created via OpenID/OAuth2. So the username field was never different from the nickname field, which is usually the case in production.

#12 Updated by kraih 3 months ago

  • Status changed from In Progress to Feedback

Everything looks good now.

#13 Updated by cdywan 2 months ago

  • Status changed from Feedback to Resolved

#14 Updated by cdywan 2 months ago

  • Copied to action #90788: openQA jobs with arbitrary parameters can be triggered over the webUI for authenticated users with right permissions (operator+) added

#15 Updated by cdywan 2 months ago

  • Subject changed from openQA jobs with arbitrary parameters can be triggered over the webUI for authenticated users with right permissions (operator+) to openQA jobs can be triggered with single curl calls

Renaming this as per what was discussed and done here, see #90788 for the web UI counterpart.

#16 Updated by cdywan 2 months ago

  • Description updated (diff)

Also available in: Atom PDF