Easier workflow to submit needles for casual contributors
- 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¶
- a comment window in the needle editor is available
- the entered comment is added in the auto-created git commit
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.
#2 Updated by okurz over 6 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)?
#4 Updated by okurz over 6 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
#10 Updated by mkittler over 1 year 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.