https://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842015-11-11T11:40:58ZopenSUSE Project Management ToolopenQA Project - action #8540: Easier workflow to submit needles for casual contributorshttps://progress.opensuse.org/issues/8540?journal_id=194922015-11-11T11:40:58ZRBrownSUSErbrown@suse.com
<ul><li><strong>Category</strong> changed from <i>138</i> to <i>Feature requests</i></li></ul> openQA Project - action #8540: Easier workflow to submit needles for casual contributorshttps://progress.opensuse.org/issues/8540?journal_id=198742015-12-14T13:19:31Zokurzokurz@suse.com
<ul></ul><p>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)?</p>
openQA Project - action #8540: Easier workflow to submit needles for casual contributorshttps://progress.opensuse.org/issues/8540?journal_id=211982016-02-04T00:21:03Zokurzokurz@suse.com
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Feedback</i></li></ul> openQA Project - action #8540: Easier workflow to submit needles for casual contributorshttps://progress.opensuse.org/issues/8540?journal_id=214062016-02-10T17:55:55Zokurzokurz@suse.com
<ul></ul><p>From today's discussion on freenode:</p>
<pre><code>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
</code></pre> openQA Project - action #8540: Easier workflow to submit needles for casual contributorshttps://progress.opensuse.org/issues/8540?journal_id=333562016-12-01T19:20:38Zokurzokurz@suse.com
<ul><li><strong>Subject</strong> changed from <i>Easier workflow to submit needles</i> to <i>Easier workflow to submit needles for casual contributors</i></li><li><strong>Status</strong> changed from <i>Feedback</i> to <i>New</i></li><li><strong>Target version</strong> set to <i>future</i></li></ul> openQA Project - action #8540: Easier workflow to submit needles for casual contributorshttps://progress.opensuse.org/issues/8540?journal_id=1296612018-06-15T19:07:35Zokurzokurz@suse.com
<ul><li><strong>Target version</strong> changed from <i>future</i> to <i>future</i></li></ul> openQA Project - action #8540: Easier workflow to submit needles for casual contributorshttps://progress.opensuse.org/issues/8540?journal_id=2745382020-01-26T16:06:16Zokurzokurz@suse.com
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/274538/diff?detail_id=270842">diff</a>)</li></ul><p>Incorporated content from <a class="issue tracker-4 status-6 priority-4 priority-default closed" title="action: Review support for needle changes (Rejected)" href="https://progress.opensuse.org/issues/10144">#10144</a> as it's about equally old and similar :)</p>
openQA Project - action #8540: Easier workflow to submit needles for casual contributorshttps://progress.opensuse.org/issues/8540?journal_id=2745442020-01-26T16:06:40Zokurzokurz@suse.com
<ul><li><strong>Related to</strong> <i><a class="issue tracker-4 status-6 priority-4 priority-default closed" href="/issues/10144">action #10144</a>: Review support for needle changes</i> added</li></ul> openQA Project - action #8540: Easier workflow to submit needles for casual contributorshttps://progress.opensuse.org/issues/8540?journal_id=3801012021-01-25T09:46:40Zokurzokurz@suse.com
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>Low</i></li></ul> openQA Project - action #8540: Easier workflow to submit needles for casual contributorshttps://progress.opensuse.org/issues/8540?journal_id=3807852021-01-28T12:50:19Zmkittlermarius.kittler@suse.com
<ul></ul><p>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.</p>