QA (public)

https://github.com/os-autoinst/qa-tools-backlog-assistant/pull/12 and https://github.com/os-autoinst/qa-tools-backlog-assistant/pull/13

EDIT: Both PRs received updates so the base branch name did not matter. Trying with more conditions, e.g. that the change is not a pull request event or something: https://github.com/os-autoinst/qa-tools-backlog-assistant/pull/14

If that does not work maybe I can still restrict the branches even though the event is schedule based. Or use something from https://www.jeffgeerling.com/blog/2020/running-github-actions-workflow-on-schedule-and-other-events which states that the following is possible:

on:
  push:
  pull_request:
  schedule:
    - cron: '*/15 * * * *'

so at least I know that I can run the same action on multiple different events.

jbaier_cz wrote:

okurz wrote:

Seems like the best solution would be to push to gh-pages instead

It is already among suggestions.

By the way, why do we have this ticket in feedback?

I was mostly waiting for other opinions and pull requests and results from CI pipelines in the various branches.

Should we set it to new and estimate to make it workable? Or make it actually resolved, because some one did the job without bothering with the usual ticket workflow?

Yes, it's resolved because https://os-autoinst.github.io/qa-tools-backlog-assistant/ shows the always current state and there are no pushes to master or other branches except gh-pages anymore.

Regarding the "usual ticket workflow": There is no strict policy that all tickets must be "Workable" before they are picked up. https://progress.opensuse.org/projects/qa/wiki#How-we-work-on-our-backlog explains that as well. However, we should look out to resolve all tickets within a reasonable time with "Low" tickets being the exception that can be treated as "idle tasks" that are only progressing if there is nothing more urgent. That also happened here so this is why the duration is 18 days but the effort is well below 1 day overall.