Re: Taskbot: TAP vs Subunit

Lucas, do you use any library for producing TAP format? Also, do you have any TAP parser, or do you just emit it? I was looking for something in Python, but all I got is either outdated, or non-complete. Thanks, Joza ___ qa-devel mailing list qa-deve

Re: Taskbot: TAP vs Subunit

- Original Message - > From: "Nick Coghlan" > > I also realised that the YAML support in TAP likely gives you the > ability to embed whatever you want if you discover the need, so it may > make sense to start with the simpler format and make use of that > embedded capability to transport

Re: RFC: Taskotron task description format

Hi Tim, sorry for the late reply, this somewhat slipped my mind :( Overall, I like the concept, and although I understand that this is Proof-of-Concept, I'm a bit worried about the get_argparser() method

Re: D19 Comments and Diff

- Original Message - > From: "Tim Flink" > To: qa-devel@lists.fedoraproject.org > Sent: Wednesday, March 5, 2014 8:23:31 PM > Subject: Re: D19 Comments and Diff > > I'm generally of the mind that folks shouldn't have to dive into > docstrings on tests in order to understand what is being

Re: Default invocation of pytest for qadevel projects

> Any thoughts on which of those (if either) would be better? I do not really mind either, and do not have any strong preference. I'm used to having the non-functional tests run by default, but I can easily manage any way we decide to do it. j. ___ qa

Re: Project Locations and Basic Setup

> - use gitflow and set 'develop' as the default branch > - host projects under bitbucket/fedoraqa >* makes it easier to say "find our projects at this url" instead of > "find projects X,Y and Z here. find A and B here" Absolutely no problem here. > - code submissions and issues/tasks

Re: Documentation and Docstring Format

> https://pythonhosted.org/an_example_pypi_project/sphinx.html#auto-directives > > > I'm not suggesting that we drop everything and fix all the docstrings > right now but I am suggesting that we start following the sphinx > docstring format for new code and fix other-formatted docstrings as we >

Re: Coding Style

> Outside any header requirements or directive documentation requirements, > are there any changes to PEP8 that folks want to make? If so, please > list the exceptions and why you think they should be adopted. How about: [FORMAT] # Maximum number of characters on a single line. max-line-len

Re: Coding Style

First of all - forget the max-line-length comment from earlier... I went through the pep8's configuration options, and there is basically next to none, so the overall decision will mostly need to be "keep it or drop it". > E251 = > Josef is used to add spaces between keyword name and it

Re: Coding Style

> But if there's a strong desire for more columns, I'll manage. Can't hinder > the team, can I? :) Also, we should mention that by default the maximal line length is set to 79, not 80. Let's just set it to 80 (as we already use it in the code), and forget about the heretic 100 idea :) _

Re: relval progress report

Cool stuff, Adam! where can I submit patches for review? :) ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel

Re: openqa_fedora_tools patch: add 'all' mode

Adam, the run_all code does not really make much sense to me, to be honest. After some minor cleanup, the code looks like this: 171 def run_all(args, wiki=None): 172 """Do everything we can: test both Rawhide and Branched nightlies 173 if they exist, and test current compose if it's diffe

Re: testdays is down again

> ... > it's down :( Seems to be working for me. Could you describe "down" a bit more? :) J. ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel

Re: openQA live image testing: ready for merge?

Adam, please set these up for review in Phabricator. I strongly suspect (given the time that I spent looking at the changes so far) that some discussion will be required, and Phab is _the_ place to do it. Also, please make sure to rebase your repos to their current state, before creating the ph

Re: openQA live image testing: ready for merge?

Some preliminary feedback: = openqa_fedora = == _do_install_and_reboot.pm == Please delete the "anaconda_install_finish" needle, if it is unused. anaconda_install_done needle: * Why is only a part of the button selected? * What is the logic behind "assert_and_click" for multiple areas in o

Re: 2015-06-01 Fedora QA Devel Meeting Minutes

> * tflink to pester jskladan Sorry about that, /me misread some old "let's cancel the meeting" email... ad Testdays: The Testday revamp is about half-done, as the process was interrupted by testing spree. I'm all in for 'killing' the old cloud machine, and I think it can be done ASAP. Th

Re: Coding Style

> > > I'm not picking on Josef here - I'm sure I've submitted code recently > > > with lint errors, this was just the review I was looking at which > > > triggered the idea: > > > > > > https://phab.qadevel.cloud.fedoraproject.org/D389 No worries, I'm not taking it personaly. As I commented in t

Re: Coding Style

- Original Message - > From: "Kamil Paral" > > Will we try to live with it in libtaskotron for a while, or should I create > similar patches for all our projects right away? I vote for doing it everywhere. I have already converted the ExecDB using autopep8 `autopep8 -r --max-line-lengt

Re: 2015-07-27 @ 14:00 UTC - Fedora QA Devel Meeting

I won't be able to make it to the meeting today, so please just C&P these: #topic jskladan's update #info T414 is cursed /me spent most of the week getting distracted by OtherThings(tm) #info Docker is broken (machines can't be linked) - BUG #1244124 #info when `git apply` is misbehaving, check C

Re: 2015-08-24 @ 14:00 UTC - Fedora QA Devel Meeting

I won't be able to participate today - last minute change of plans out of my control - but I have no status updates anyway - most of the time was spent on catching up with things after Flock, and expense reports (yay!). I'm, on the other hand, in need of tasks, so feel free to throw some my way

Re: Log Data Retention

> ... to delete all artifacts older than 4 months. If you have objections, > speak up now. OK with me. ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel

Testcase namespacing - adding structure to result reporting

This is an initial take on stuff that was discussed in person during Tim's stay in Brno. Sending to the list for additional discussion/fine-tuning. = What = Talking rpmgrill-like checks, there will be a need to be able to facilitate some kind of structure for representing that a check is compose

Re: 2016-02-22 @ 15:00 UTC - Fedora QA Devel Meeting

Top posting for consistence. Also, I won't be able to come today. How about postponing the meeting until tomorrow? J. - Original Message - > From: "Jan Sedlak" > To: "Fedora QA Development" > Sent: Monday, February 22, 2016 12:41:50 PM > Subject: Re: 2016-02-22 @ 15:00 UTC - Fedora QA D

Re: Proposal to CANCEL: 2016-03-21 Fedora QA Devel Meeting

ack On Mon, Mar 21, 2016 at 6:47 AM, Tim Flink wrote: > I don't have any hugely important topics for the QA Devel meeting this > week so instead of taking up 30-60 minutes of everyone's time this > week, I propose that the meeting be canceled. > > If there is a topic that you would like to see d

On Docker testing and pytest

Resending to keep things public... tl;dr; of the tl;dr; https://www.youtube.com/watch?v=3DWB7CBdvXU tl;dr; Tim and I/lbrabec shared the same worry, that by being overly-facilitating to docker, we might go into the spiral of doom, where in the end we'd have to have and support specific tooling f

2016-04-11 @ 14:00 UTC - Fedora QA Devel Meeting

# Fedora QA Devel Meeting # Date: 2016-04-04 # Time: 14:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting-1 on irc.freenode.net It's been a few weeks since we had our last QA devel meeting and I'm sure that everyone is chomping at the bit to get back to th

Re: 2016-04-11 @ 14:00 UTC - Fedora QA Devel Meeting

On Mon, Apr 11, 2016 at 2:49 PM, Josef Skladanka wrote: > > ... I won't be able to come today, updates are in the phriction document. I'm going to mess around with the image building scripts a bit (I want to make the failure reporting a bit more sane), but could use some task

PoC of "configurable trigger"

Source: https://bitbucket.org/fedoraqa/taskotron-trigger/branch/pony Diff: https://phab.qadevel.cloud.fedoraproject.org/D872 This started as simple bike-shedding to make more sense in naming (so everything is not named "Trigger"), but it went further :D The main change here is, what I call "confi

Re: Request for Testing: New Auth Method for Phabricator

Linking the account worked for me just fine, although I stumbled upon the Err 500 while trying to log-in via persona (worked on the second try, though). After logging out, and re-logging in via Ipsilon for the first and third time, this is what I got: Unhandled Exception ("HTTPFutureHTTPResponseSt

Resultsdb v2.0 - API docs

Hey gang, I spent most of today working on the new API docs for ResultsDB, making use of the even better Apiary.io tool. Before I put even more hours into it, please let me know, whether you think it's fine at all - I'm yet to find a better tool for describing APIs, so I'm definitely biased, but

Re: Resultsdb v2.0 - API docs

#x27;d love for this to be stable (or at least a base for non-breaking changes) for at least next few years (lol I know, right...), so let's do it right :) joza On Mon, Aug 15, 2016 at 10:48 PM, Josef Skladanka wrote: > Hey gang, > > I spent most of today working on the new A

"New" trigger ready

Hey gang, so this Differential: https://phab.qadevel.cloud.fedoraproject.org/D963 and this branch: https://bitbucket.org/fedoraqa/taskotron-trigger/branch/feature/rules_engine (was force-pushed to couple of times, so make sure to re-clone it) now contain the final implementation of the "new trigge

Re: Resultsdb v2.0 - API docs

On Tue, Sep 13, 2016 at 8:19 PM, Randy Barlow wrote: > Will the api/v1.0/ endpoint continue to function as-is for a while, to > give integrators time to adjust to the new API? That would be ideal for > Bodhi, so we can adjust our code to work with v2.0 after it is already in > production. If not,

Re: Resultsdb v2.0 - API docs

On Mon, Sep 12, 2016 at 11:39 PM, Tim Flink wrote: > > I think we talked about this in person earlier but I didn't write any > notes about it and I don't recall the details. > > How exactly are we going to be using Groups? The first thing that comes > to mind is to group results by execution so t

Re: RFR: New Dist-Git Task Storage Proposal

On Tue, Sep 13, 2016 at 4:20 PM, Tim Flink wrote: > On Mon, 12 Sep 2016 14:44:27 -0600 > Tim Flink wrote: > > > I wrote up a quick draft of the new dist-git task storage proposal > > that was discussed in Brno after Flock. > > > > https://phab.qadevel.cloud.fedoraproject.org/w/taskotron/ > new_d

Re: Resultsdb v2.0 - API docs

On Thu, Sep 15, 2016 at 4:20 PM, Tim Flink wrote: > On Mon, 15 Aug 2016 22:48:38 +0200 > Josef Skladanka wrote: > > > Hey gang, > > > > I spent most of today working on the new API docs for ResultsDB, > > making use of the even better Apiary.io tool. > > &

Re: 2016-09-14 @ 14:00 UTC - QA Tools Video "Standup" Meeting

I'd rather go with the option no. 1, but I don't really care that much either way. So if one option suits you guys better, I'll comply. J. On Thu, Sep 22, 2016 at 9:59 AM, Martin Krizek wrote: > - Original Message - > > From: "Tim Flink" > > To: qa-devel@lists.fedoraproject.org > > Sen

Re: Resultsdb v2.0 - API docs

On Tue, Sep 27, 2016 at 6:06 PM, Kamil Paral wrote: > ... > What are the use cases? I can think of one - yesterday Adam mentioned he > would like to save manual test results into resultsdb (using a frontend). > That would have no ExecDB entry (no UUID). Is that a problem in the current > design?

Re: Resultsdb v2.0 - API docs

So, what's the decision? I know I can "guesstimate", but I'd like to see a group consensus before I actually start coding. On Thu, Sep 29, 2016 at 7:31 AM, Josef Skladanka wrote: > > > On Tue, Sep 27, 2016 at 6:06 PM, Kamil Paral wrote: > >> ... >>

New ExecDB

With ResultsDB and Trigger rewrite done, I'd like to get started on ExecDB. The current ExecDB is more of a tech-preview, that was to show that it's possible to consume the push notifications from Buildbot. The thing is, that the code doing it is quite a mess (mostly because the notifications are

Re: New ExecDB

On Tue, Oct 11, 2016 at 1:14 PM, Kamil Paral wrote: > Proposal looks good to me, I don't have any strong objections. > > 1. If you don't like blame: UNIVERSE, why not use blame: TESTBENCH? > 2. I think that having enum values in details in crash structure would be > better, but I don't have stron

Re: New ExecDB

So, after a long discussion, we arrived to this solution. We will clearly split up the "who to notify" part, and "should we re-schedule" part of the proposal. The party to notify will be stored in the `notify` field, with `taskotron, task, unknown` options. Initially any crashes in `shell` or `pyt

Re: Proposal to CANCEL: 2016-10-31 Fedora QA Devel Meeting

+1 to cancel On Mon, Oct 31, 2016 at 5:58 AM, Tim Flink wrote: > I'm not aware of any topics that need to be discussed/reviewed as a > group this week, so I propose that we cancel the weekly Fedora QA devel > meeting. > > If there are any topics that I'm forgetting about and/or you think > shoul

ResultsDB 2.0 - DB migration on DEV

So, I have performed the migration on DEV - there were some problems with it going out of memory, so I had to tweak it a bit (please have a look at D1059, that is what I ended up using by hot-fixing on DEV). There still is a slight problem, though - the migration of DEV took about 12 hours total,

Re: Release validation NG: planning thoughts

On Mon, Nov 28, 2016 at 6:48 PM, Adam Williamson wrote: > On Mon, 2016-11-28 at 09:40 -0800, Adam Williamson wrote: > > The validator/submitter component would be responsible for watching out > > for new composes and keeping track of tests and 'test environments' (if > > we keep that concept); it

Re: Release validation NG: planning thoughts

On Tue, Nov 29, 2016 at 5:34 PM, Adam Williamson wrote: > On Tue, 2016-11-29 at 19:41 +0530, Kanika Murarka wrote: > > 2. Keep a record of no. of validation test done by a tester and highlight > > it once he login. A badge is being prepared for no. of validation testing > > done by a contributor[

Re: Release validation NG: planning thoughts

On Wed, Nov 30, 2016 at 11:10 AM, Adam Williamson < adamw...@fedoraproject.org> wrote: > On Wed, 2016-11-30 at 09:38 +0100, Josef Skladanka wrote: > > So if this is what you wanted to do (data validation), it might be a good > > idea to have that submitter middleware. > &g

Re: Release validation NG: planning thoughts

On Wed, Nov 30, 2016 at 11:14 AM, Adam Williamson < adamw...@fedoraproject.org> wrote: > On Wed, 2016-11-30 at 02:10 -0800, Adam Williamson wrote: > > On Wed, 2016-11-30 at 09:38 +0100, Josef Skladanka wrote: > > > So if this is what you wanted to do (data validatio

Re: Release validation NG: planning thoughts

On Thu, Dec 1, 2016 at 6:04 PM, Adam Williamson wrote: > On Thu, 2016-12-01 at 14:25 +0100, Josef Skladanka wrote: > > On Wed, Nov 30, 2016 at 6:29 PM, Adam Williamson < > adamw...@fedoraproject.org > > > wrote: > > > On Wed, 2016-11-30 at 18:20 +0100, Josef Skl

Re: ResultsDB 2.0 - DB migration on DEV

On Mon, Dec 5, 2016 at 4:25 PM, Tim Flink wrote: > Is there a way we could export the results as a json file or something > similar? If there is (or if it could be added without too much > trouble), we would have multiple options: > Sure, adding some kind of export should be doable > > 1. Dump

Re: ResultsDB 2.0 - DB migration on DEV

-- since the db's were 'cloned' at the beginning, perform deletion of the inverse set of data than we did in archive =# delete from result_data where result_id < 7857665; =# delete from result where id < 7857665; =# delete from job where id < 308902; On Wed, Dec 7, 2016 at

Re: 2016-12-15 @ 17:00 UTC - Outage for qadevel.cloud replacement

Awesome! On Wed, Dec 14, 2016 at 6:54 PM, Tim Flink wrote: > I realize this is a little last minute but there's no telling how much > longer the current auth system will continue to work. > > I'm planning to take qadevel down (phabricator, some docs etc.) > tomorrow so that I can finally replace

Re: Proposal to CANCEL: 2016-12-19 Fedora QA Devel Meeting

+1, especially since all the relevant pepole here are on PTO. On Mon, Dec 19, 2016 at 5:34 AM, Tim Flink wrote: > Most of the regular folks will be absent this week and I'm not aware of > anything urgent to cover so I propose that we cancel the weekly Fedora > QA devel meeting. > > If there are

Re: Proposal to CANCEL: 2017-01-02 Fedora QA Devel Meeting

Agreed On Sun, Jan 1, 2017 at 7:28 PM, Tim Flink wrote: > Monday is a holiday for me and I suspect that it is also a holiday for > many other folks. I'm not aware of anything urgent which needs > discussion so I'm proposing that we cancel our normally scheduled QA > devel meeting. > > If there a

Re: New ExecDB

ally started on removing the tight coupling between execdb and buildbot, and then I went on trying to figure out what's in this thread. On Tue, Jan 10, 2017 at 6:57 AM, Tim Flink wrote: > On Fri, 21 Oct 2016 13:16:04 +0200 > Josef Skladanka wrote: > > > So, after a long disc

Re: Enabling running Taskotron tasks on Koji scratch builds

I don't have much to add, just that I agree with Kamil. I see some minor problems even in what he wrote, but that's well beyond what I think we should be solving now. j. On Tue, Jan 10, 2017 at 5:19 PM, Kamil Paral wrote: > > Couldn't we use the task ID as the primary identifier but use the srp

Re: Task Result Dashboards

On Thu, Jan 12, 2017 at 7:42 AM, Tim Flink wrote: > The idea was to start with static site generation because it doesn't > require an application server, is easy to host and likely easier to > develop, at least initially. > > I don't really have a strong preference either way, just wanted to say

Re: Proposal: Migrating More Git Projects to Pagure

I don't have any serious issues, as long as we only use pagure as git host. I hate that "we wanted to copy github, but stopped just after we found out it's too much functionality" thing (also don't like how github works on top of that, so even a 1:1 clone would be awful from my perspective). Just

Re: Proposal: Migrating More Git Projects to Pagure

On Fri, Jan 13, 2017 at 2:11 PM, Kamil Paral wrote: > > I don't have any serious issues, as long as we only use pagure as git > host. I > > hate that "we wanted to copy github, but stopped just after we found out > > it's too much functionality" thing (also don't like how github works on > top >

Re: Proposal: Migrating More Git Projects to Pagure

On Fri, Jan 13, 2017 at 5:49 PM, Adam Williamson wrote: > On Fri, 2017-01-13 at 14:16 +0100, Josef Skladanka wrote: > > > I am personaly against issues/pull requests on Pagure - logging into > Phab > > is about as difficult as logging into Pagure, and I don't see th

Re: OpenQA templates with hardcoded nfs address

On Wed, Jan 18, 2017 at 3:19 PM, Normand wrote: > I am looking at the nfs tests already defined in OpenQA templates file for > fedora (1) > > I would like to try those tests locally in a PowerPC environment, > so plan to modify templates to replace the hardcoded value > by a variable to be set by

Re: Proposal to CANCEL: 2017-01-23 Fedora QA Devel Meeting

+1 On Mon, Jan 23, 2017 at 10:19 AM, Tim Flink wrote: > There are a bunch of Red Hat related events this week and a majority > of the usual suspects are going to be busy with other things. I'm not > aware of any urgent topics that need to be discussed/reviewed as a group > this week, so I propos

Re: ResultsDB 2.0 - DB migration on DEV

So I started the data migration for the STG archives - should be done in about 15 hours from now (running for cca six hours already) - estimated on the number of results that were already converted. If that goes well, I'll start the PROD archives migration tomorrow, and start working on merging the

Re: ResultsDB 2.0 - DB migration on DEV

STG is done (took about 15 hours), starting the archive migration for PROD, and I'll start figuring way to merge the data. Probably tomorrow. On Tue, Jan 24, 2017 at 5:49 PM, Josef Skladanka wrote: > So I started the data migration for the STG archives - should be done in > about 15

Static dashboards PoC

Folks, lbrabec and I made the static dashboards happen, a sample can be seen here: https://jskladan.fedorapeople.org/dashboards/ Note that these are all generated from a yaml config that defines the packages/testcases + real resultsdb data. Not that the dashboards make much sense, but it shows of

Re: ResultsDB 2.0 - DB migration on DEV

Estimate on the PROD migration finish is in about 24 hours from now. STG was seamless, so I'm not expecting any troubles here either. On Wed, Jan 25, 2017 at 10:47 AM, Josef Skladanka wrote: > STG is done (took about 15 hours), starting the archive migration for > PROD, and I'l

Re: making test suites work the same way

On Fri, Feb 3, 2017 at 11:05 PM, Kamil Paral wrote: > I spent a bit of time fixing minor issues in our test suite and makefiles > and would like to do the following further changes across all our taskotron > projects: > > 1. run the test suite while inside virtualenv with simple `pytest` command

Lift type-restriction on ibtaskotron's cli + resultsdb directive

Hey Gang, this is bugging me for quite a while now, and although I know why we put the restrictions there back then, I'm not sure the benefits still outweigh the problems. Especially now, when we'll probably be getting some traction, I'd like to propose removing the type-check completely. On top

Libtaskotron - allow non-cli data input

Chaps, we were discussing this many times in the past, and as with the type-restriction, I think this is the right time to get this done, actually. It sure ties to the fact, that I'm trying to put together Taskotron-continuously-testing-Taskotron together - the idea here being that on each commit

Re: making test suites work the same way

On Mon, Feb 6, 2017 at 1:35 PM, Kamil Paral wrote: > > That's a good point. But do we have a good alternative here? If we depend > on packages like that, I see only two options: > > a) ask the person to install pyfoo as an RPM (in readme) > b) ask the person to install gcc and libfoo-devel as an

Re: making test suites work the same way

Well, after more discussions with kparal, we are still unsure about the "right" way to tackle this. Our current call would be: 1) sync requirements.txt versions with fedora (mostly done) 2) allow --system-site-packages in the test_env 3) do `pip install -r requirements.txt` (with possible flags to

Re: making test suites work the same way

+1 I'm glad that our usual flame-war yielded a common ground that we can agree upon :) Hope that it was not as painfull as usual. J. On Mon, Feb 6, 2017 at 6:04 PM, Kamil Paral wrote: > Well, after more discussions with kparal, we are still unsure about the > "right" way to tackle this. > Our c

Re: Lift type-restriction on ibtaskotron's cli + resultsdb directive

On Mon, Feb 6, 2017 at 6:19 PM, Kamil Paral wrote: So this is about removing `_ITEM_TYPES` from `main.py`, correct? > Yes, I could have been more specific. > > I don't have a problem with that, as long as any relevant docs are updated > and we're able to present a reasonable message when someth

Re: Libtaskotron - allow non-cli data input

On Mon, Feb 6, 2017 at 6:49 PM, Kamil Paral wrote: > The formulas already provide a way to 'query' structured data via the > dot-format, so we could do with as much as passing some variable like > 'task_data' that would contain the parsed json/yaml. > > > Or are you proposing we add another varia

Re: Libtaskotron - allow non-cli data input

On Wed, Feb 8, 2017 at 2:26 PM, Kamil Paral wrote: > This is what I meant - keeping item as is, but being able to pass another > structure to the formula, which can then be used from it. I'd still like to > keep the item to a single string, so it can be queried easily in the > resultsdb. The item

Re: Libtaskotron - allow non-cli data input

On Wed, Feb 8, 2017 at 4:11 PM, Tim Flink wrote: > On Wed, 8 Feb 2017 08:26:30 -0500 (EST) > Kamil Paral wrote: > > I think another question is whether we want to keep assuming that the > *user supplies the item* that is used as a UID in resultsdb. As you say, > it seems a bit odd to require peo

Re: Libtaskotron - allow non-cli data input

On Wed, Feb 8, 2017 at 7:39 PM, Kamil Paral wrote: > > I mentioned this in IRC but why not have a bit of both and allow input > > as either a file or on the CLI. I don't think that json would be too > > bad to type on the command line as an option for when you're running > > something manually: >

Re: Libtaskotron - allow non-cli data input

On Wed, Feb 8, 2017 at 8:06 PM, Adam Williamson wrote: > Wouldn't it be great if we had a brand new project which would be the > ideal place to represent such conventions, so the bit of taskotron > which reported the results could construct them conveniently? :P https://xkcd.com/684/ :) (I mean

Taskotron CI in Taskotron

Gang, I finally got some work done on the CI task for Taskotron in Taskotron. The idea here is that after each commit (of a relevant project - trigger, execdb, resultsdb, libtaskotron) to pagure, we will run the whole stack in docker containers, and execute a known "phony" task, to see whether it

Re: Taskotron CI in Taskotron

On Thu, Feb 9, 2017 at 5:58 PM, Matthew Miller wrote: > On Thu, Feb 09, 2017 at 03:29:13AM +0100, Josef Skladanka wrote: > > I finally got some work done on the CI task for Taskotron in Taskotron. > The > > idea here is that after each commit (of a relevant project - t

Re: Wiki page gardening

Awesome, thanks! On Fri, Feb 10, 2017 at 4:27 AM, Adam Williamson wrote: > Hi folks! I did a bit of light gardening on the Taskotron and ResultsDB > and a few other wiki pages today: > > * https://fedoraproject.org/wiki/Taskotron > * https://fedoraproject.org/wiki/Taskotron_contribution_guide >

Re: Taskotron CI in Taskotron

So, the repo now has working PoC https://pagure.io/taskotron/task-taskotron-ci Readme contains example on how to run the task. Works on my setup, and I'd be glad if somebody else tried. J. On Fri, Feb 10, 2017 at 7:31 AM, Josef Skladanka wrote: > > > On Thu, Feb 9, 2017 at 5:

ExecDB rewrite - call for comments

Hey gang! With the incoming changes, I'd like to make ExecDB a bit more worth its name, and make it less tied to Buildbot than it is at the moment, and also make some changes to what functionality it provides. Please, comment! Thanks, Joza https://docs.google.com/a/redhat.com/document/d/1sOAn2W

Re: Taskotron CI in Taskotron

On Tue, Feb 14, 2017 at 8:51 PM, Adam Williamson wrote: > Are you aware of fedmsg-dg-replay? It's a fairly easy way to 'replay' > fedmsgs for testing. All you need (IIRC) is the fedmsg-relay service > running on the same system, and you can run > I am, but it has this bad quality of changing the

Re: Taskotron CI in Taskotron

On Wed, Feb 15, 2017 at 5:55 PM, Adam Williamson wrote: > On Wed, 2017-02-15 at 12:59 +0100, Josef Skladanka wrote: > > On Tue, Feb 14, 2017 at 8:51 PM, Adam Williamson < > adamw...@fedoraproject.org > > > wrote: > > > Are you aware of fedmsg-dg-replay?

Trigger changes - call for comments

Hey, gang! As with the ExecDB, I took some time to try and formalize what I think is to be done with Trigger in the near-ish future. Since it came to my attention, that the internal G-Docs can not be accessed outside of RH, this time, it is shared from my personal account - hopefully more people w

Re: ExecDB rewrite - call for comments

Just FYi, I transformed the document (thx for the comments and nitpicks) to Phab Wiki page: https://phab.qa.fedoraproject.org/w/taskotron/execdb_rewrite/ On Wed, Feb 15, 2017 at 2:40 PM, Kamil Paral wrote: > Hey gang! > > With the incoming changes, I'd like to make ExecDB a bit more worth its >

Re: Proposal to CANCEL: 2017-03-27 QA Devel Meeting

OK On Mon, Mar 27, 2017 at 5:30 AM, Tim Flink wrote: > I have a conflict during the normal QA Devel meeting this week so > unless someone else wants to lead the meeting, I propose that we cancel > it. > > Tim > > ___ > qa-devel mailing list -- qa-devel

Re: Re-Scheduling Jobs for Taskotron as a User

On Thu, Apr 20, 2017 at 12:07 AM, Adam Williamson < adamw...@fedoraproject.org> wrote: > OK, like I said, half-baked =) But wdyt? > > Love it! (And I swear, it has nothing to do with the fact, that I also thought this would be a great way to solve it in a more generic manner.)

Re: Proposal to CANCEL: 2017-07-03 QA Devel Meeting

+1 On Sat, Jul 1, 2017 at 7:30 PM, Tim Flink wrote: > There are multiple holidays this week and I suspect that most folks > (including me) won't be around for a QA Devel meeting so I propose that > we cancel the regular meeting. > > If there is some urgent topic to discuss, reply to this thread

Discontinuing Phabricator

As you all probably know, we decided that keeping Phab up and running is not the best use of our - rather limited, and shrinking - resources, so we moved all our projects to Pagure. Yay! As of now, all (relevant) tickes are moved to Pagure, and we have the Differential revisions archived as html s

Re: Proposal to CANCEL: 2017-08-28 QA Devel Meeting

ack On Mon, Aug 28, 2017 at 5:58 AM, Tim Flink wrote: > There are more than one of us traveling to Flock on Monday and as such, > I propose that we cancel the regularly scheduled QA Devel meeting. > > If there is some urgent topic to discuss, please reply to this thread > and the meeting can hap

Re: 2017-10-16 @ 14:00 UTC - Fedora QA Devel Meeting

Looks like it will be just the two of us today, Tim - I don't have any serious updates, but I'm all for doing it, if you deem it useful. On Mon, Oct 16, 2017 at 6:36 AM, Tim Flink wrote: > # Fedora QA Devel Meeting > # Date: 2017-10-16 > # Time: 14:00 UTC > (https://fedoraproject.org/wiki/Infras

Please review - Infra Ansible - move slaves from home to srv

I'm not sure what is the best way to ask for review for a pagure-less project, since we don't use Phabricator any more, so... let the funmail begin: diff --git a/inventory/host_vars/qa10.qa.fedoraproject.org b/inventory/host_vars/qa10.qa.fedoraproject.org index 297f614e3..d2119dc47 100644 --- a/i

Re: Please review - Infra Ansible - move slaves from home to srv

The raw diff was attached to the original email, I could have mentioned that, I guess. /me was not able to make gmail send unformatted/unwrapped text. Sorry for the inconvenience. j. On Mon, Nov 20, 2017 at 6:32 PM, Tim Flink wrote: > On Mon, 20 Nov 2017 10:36:03 +0100 > Josef Skladanka

Re: Proposal to CANCEL: 2018-02-05 QA Devel Meeting

ACK On Sun, Feb 4, 2018 at 10:26 PM, Tim Flink wrote: > I'm not aware of any topics that need urgent discussion this week, so I > propose that we cancel the QA Devel meeting on 2018-02-05. > > If there are some topics that need discussing, please reply here and > the meeting can happen. > > Tim

status report

= Highlights = * Participated in interviewing candidates to replace Petr * Deployed Vault on dev * there still are some quirks with OIDC login, that I need to iron out, but the overall concept seems good for the usecase * Modified libtaskotron to allow grabbing secrets from the Vault < https://p

Re: status report

Sorry, wrong list. I blame the heat! On Sun, Jun 10, 2018 at 5:19 PM, Josef Skladanka wrote: > = Highlights = > > * Participated in interviewing candidates to replace Petr > * Deployed Vault on dev > * there still are some quirks with OIDC login, that I need to iron out, &g

Re: orphaning Taskotron-related packages

On Mon, Nov 23, 2020 at 7:11 PM Tim Flink wrote: > > On Thu, 12 Nov 2020 18:25:17 +0100 > Kamil Paral wrote: > > > Note: The email subject should have said "retiring" instead of > > "orphaning". There is little reason to orphan them, retiring is the > > right approach here. Perhaps except for mon