action #8540
open
Easier workflow to submit needles for casual contributors
Added by ancorgs about 9 years ago.
Updated over 3 years ago.
Category:
Feature requests
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.
- Category changed from 138 to Feature requests
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)?
- Status changed from New to Feedback
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
- 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
- Target version changed from future to future
- Description updated (diff)
Incorporated content from #10144 as it's about equally old and similar :)
- Related to action #10144: Review support for needle changes added
- Priority changed from Normal to Low
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