action #8540


Easier workflow to submit needles for casual contributors

Added by ancorgs over 8 years ago. Updated about 3 years ago.

Feature requests
Target version:
Start date:
Due date:
% Done:


Estimated time:


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


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 1 (0 open1 closed)

Related to openQA Project - action #10144: Review support for needle changesRejectedokurz2016-01-07

Actions #1

Updated by RBrownSUSE over 8 years ago

  • Category changed from 138 to Feature requests
Actions #2

Updated by okurz over 8 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)?

Actions #3

Updated by okurz about 8 years ago

  • Status changed from New to Feedback
Actions #4

Updated by okurz about 8 years ago

From today's discussion on freenode:

1: […] it broke here ; I wanted to fix it but my account on 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 (see 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
Actions #5

Updated by okurz over 7 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
Actions #6

Updated by okurz almost 6 years ago

  • Target version changed from future to future
Actions #7

Updated by okurz about 4 years ago

  • Description updated (diff)

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

Actions #8

Updated by okurz about 4 years ago

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

Updated by okurz about 3 years ago

  • Priority changed from Normal to Low
Actions #10

Updated by mkittler about 3 years ago

About US1: I've already came up with a relevant idea when thinking about the "better version control" story in general: We could push to a special branch and open GitHub's or GitLabs's PR creation page from it. This would allow a review by others before directly pushing the commit to master.


Also available in: Atom PDF