Project

General

Profile

action #8540

Easier workflow to submit needles for casual contributors

Added by ancorgs about 5 years ago. Updated 8 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Feature requests
Target version:
Start date:
2015-08-19
Due date:
% Done:

0%

Estimated time:
Difficulty:

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 changesRejected2016-01-07

History

#1 Updated by RBrownSUSE almost 5 years ago

  • Category changed from 138 to Feature requests

#2 Updated by okurz almost 5 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 over 4 years ago

  • Status changed from New to Feedback

#4 Updated by okurz over 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 almost 4 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 2 years ago

  • Target version changed from future to future

#7 Updated by okurz 8 months ago

  • Description updated (diff)

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

#8 Updated by okurz 8 months ago

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

Also available in: Atom PDF