Project

General

Profile

Actions
Copy link

action #102335

closed

qa-tools-backlog-assistant: Automated runs of the workflow are making pull requests impossible to accept

Added by jbaier_cz about 3 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
Low
Assignee:
okurz
Target version:
openQA Project - Ready
Start date:
2021-11-12
Due date:
% Done:

0%

Estimated time:

Description

Motivation

As stated in a comment we are not able to accept pull request for qa-tools-backlog-assistant due to the workflow pushing into master.

Acceptance criteria

AC1: Readme is a static file without constant updates
AC2: Pull request are not made complicated to accept due to the tool daily invocation

Suggestions

Actions
Copy link
 #1

Updated by okurz about 3 years ago

  • Status changed from New to In Progress
  • Assignee set to okurz
Actions
Copy link
 #2

Updated by okurz about 3 years ago

  • Status changed from In Progress to Feedback

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.

Actions
Copy link
 #3

Updated by okurz almost 3 years ago

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

Actions
Copy link
 #4

Updated by jbaier_cz almost 3 years ago

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? 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?

Actions
Copy link
 #5

Updated by okurz almost 3 years ago

  • Status changed from Feedback to Resolved

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.

Actions
Copy link

Also available in: Atom PDF