action #8540

Easier workflow to submit needles for casual contributors

Added by ancorgs over 4 years ago. Updated 27 days ago.

Status:NewStart date:19/08/2015
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Feature requests
Target version:QA - future
Difficulty:
Duration:

Description

User stories

  • US1: As a test developer / reviewer changing needles I want my proposed needle changes to be reviewed to let others review my changes
  • US2: As a meta-reviewer I can see who changed needles when and why to distinguish different test failure causes

US1: TODO

US2: Comment for changes in needle editor

acceptance criteria

  • a comment window in the needle editor is available
  • the entered comment is added in the auto-created git commit

Further details

Original story from ancorgs:
During a recent meeting we discussed the possibility of making easier for casual contributors to submit needles, maybe allowing direct submissions from other openQA instances. Just something to think about for the time being.


Related issues

Related to openQA Project - action #10144: Review support for needle changes Rejected 07/01/2016

History

#1 Updated by RBrownSUSE over 4 years ago

  • Category changed from 138 to Feature requests

#2 Updated by okurz about 4 years ago

What exactly are the use cases (or user stories) for submitting needles if not using the internal needle editor which directly saves needles, puts them in a git repo and pushes them? Do you have in mind to run openQA on machine 1 (e.g. local test instance) and making the internal needle editor to submit to an openQA on machine 2 (e.g. openqa.o.o)?

#3 Updated by okurz about 4 years ago

  • Status changed from New to Feedback

#4 Updated by okurz about 4 years ago

From today's discussion on freenode:

1: […] it broke here https://progress.opensuse.org/issues/10652 ; I wanted to fix it but my account on openqa.suse.de cannot edit needles
2: I if promote your account to "operator", I think your needles will go directly to the repository, without pull request. Not sure if that's what the openQA guys want
2: but I can give you that access
1: I know, bypassing PRs is bad. but the workflow sucks: either I push directly, or can edit nothing and must use a different openqa instance, right?
1: what I'd like is editing on the main server but pushing to my fork with PRs. so that's a potential improvement to openqa; but what should we do now
<okurz>: I am new with the openQA team since three months but what I prefer is to reproduce everything locally and provide PRs for review for both tests *and* needles. If you say a local openQA instance setup is hard to do that is something that we can try to improve of course
1: for the record, I *did* set up my own instance of openqa some months ago, made 1 or 2 fixes that way, and hated the cumbersome process.
[…]
2: I have a question about occassional contributions to broken openqa tests. 1 wants to fix a broken needle in openqa.opensuse.org (see https://progress.opensuse.org/issues/10652) If we make him operator, the needle will go to the needles repository directly (no pull request, no chance to review). Right? needling is an art, so 1 feels more confident opening a pull request but that would mean having a separate instance of openQA and reproducing the failure there. As we know, it's not that easy to keep a installation of openQA running and up-to-date just for occasional use. how do we handle that?
3: we make him operator and revert if they are shit
3: oh and of course we make him swear on his grandma that he won't touch things he has no business with without asking ;)
2: of course :-) grandma-driven security
<okurz>: Besides "running your local openQA" and "do everything on the productive instance" I can think of two possibilities: 1. Make the pull requests available in branches of a test version of the test distribution and manually trigger builds which don't show up in the product screens to verify first before merging 2. Create a "playground server". nr 2 will probably not work because "playground" means someone will break it and others don't know what happened so it is too much work, I guess

#5 Updated by okurz about 3 years ago

  • Subject changed from Easier workflow to submit needles to Easier workflow to submit needles for casual contributors
  • Status changed from Feedback to New
  • Target version set to future

#6 Updated by okurz over 1 year ago

  • Target version changed from future to future

#7 Updated by okurz 27 days ago

  • Description updated (diff)

Incorporated content from #10144 as it's about equally old and similar :)

#8 Updated by okurz 27 days ago

  • Related to action #10144: Review support for needle changes added

Also available in: Atom PDF