Skip to content

Document how to schedule tests via @openqa: in a GHA #6834

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
kalikiana wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Document how to schedule tests via @openqa: in a GHA #6834

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 25 additions & 5 deletions docs/WritingTests.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2330,11 +2330,31 @@ feature is explained in further detail in the corresponding
<<UsersGuide.asciidoc#scenarios_yaml,users guide section>>.

It is also possible to create a GitHub workflow that will clone and monitor an
openQA job which is mentioned in the PR description or comment. The scripts
repository contains a pre-defined GitHub action for this. Checkout the
documentation of the
https://github.com/os-autoinst/os-autoinst-scripts/blob/master/openqa-clone-and-monitor-job-from-pr[openqa-clone-and-monitor-job-from-pr]
script for further information and an example configuration.
openQA job which is mentioned in the PR description using https://github.com/os-autoinst/os-autoinst-scripts/blob/master/openqa-clone-and-monitor-job-from-pr[openqa-clone-and-monitor-job-from-pr] with something like this:

----
name: Schedule openQA tests mentioned via @openqa:
on:
pull_request_target:
workflow_dispatch:
env:
OPENQA_HOST: ${{ secrets.OPENQA_URL }}
OPENQA_API_KEY: ${{ secrets.OPENQA_API_KEY }}
OPENQA_API_SECRET: ${{ secrets.OPENQA_API_SECRET }}
GH_REPO: ${{ github.event.pull_request.head.repo.full_name }}
GH_REF: ${{ github.event.pull_request.head.ref }}
GH_PR_BODY: ${{ github.event.pull_request.body }}
jobs:
clone_and_monitor_job_from_pr:
runs-on: ubuntu-latest
container:
image: registry.opensuse.org/devel/openqa/containers/tumbleweed:client
steps:
- uses: os-autoinst/os-autoinst-scripts/actions/clone-job@master
----
Comment on lines +2335 to +2354
Copy link
Contributor

@Martchus Martchus Nov 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we really add a copy of this here? Isn't it enough if we just refer to the documentation within the script itself? With your change we'll have to keep both places in-sync.

Copy link
Member Author

@kalikiana kalikiana Nov 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The script itself contains examples if you mean that. I don't find that very discoverable or accessible.

Copy link
Contributor

@Martchus Martchus Nov 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But we are referring to it explicitly making it discoverable.

Copy link
Member Author

@kalikiana kalikiana Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Docs from os-autoinst-scripts don't end up on open.qa/docs...

Copy link
Member

@okurz okurz Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Docs from os-autoinst-scripts don't end up on open.qa/docs...

That's true but if one follows the link to a nicely rendered markdown README from os-autoinst-scripts that should suffice


In this example the body of the PR is passed via `GH_PR_BODY`. Comments can also
be provided but this requires use of the GitHub API via the comments endpoint.

NOTE: These examples show how API credentials are supplied. It is important to
note that using `on:pull_request` would only work for PRs created on the main
Expand Down