- User Since
- Nov 7 2013, 8:47 AM (202 w, 4 d)
Aug 7 2017
commandeering to abandon
Commandeering to close
Guys, note that we just officially stopped using Phabricator. It is not being powered off right now, but I suggest moving the diff, and conversation to an appropriate pagure repo as a PR https://pagure.io/fedora-qa/os-autoinst-distri-fedora. Note that the discussion is archieved here: https://fedorapeople.org/groups/qa/phabarchive/differentials/phab.qa.fedoraproject.org/D1083.html
Hey, guys, just a note here - we just officially seized using Phabricator. This does not necessarily change much for you - we are not powering it off right now, but we stopped tracking it. If you come to the final version of the diff, please create a PR against ResultsDB at Pagure https://pagure.io/taskotron/resultsdb, also note, that the contents of the debate/last diff is archived here https://fedorapeople.org/groups/qa/phabarchive/differentials/phab.qa.fedoraproject.org/D1206.html, if you wanted to reference it in the future.
Best, your friendly FedoraQA!
Merged to resultsdb. This seemed fine, but if it does not, let me know @ralph
Merged, thanks! Hopefully phab will reflect this shortly.
This was, in the end, not fine, but I based a fix on this, which will, hopefully close this diff shortly.
Aug 1 2017
As we discussed lately, it is wise to try replacing buildbot with Jenkins - not only is it a pleasing decision, but it might be practical, as we might start using somebody else's infrastructure (CentosCI comes to mind), and get rid of some of the sysadmining.
Jul 27 2017
Already used on Taskotron landing page(s) for quite a time
Jul 26 2017
Jul 17 2017
Jul 14 2017
Jul 12 2017
Jul 11 2017
This is fine. At least before we have a better solution - I'd go with diff applied on top of the yumrepoinfo downloaded from repos, or installed from package, so we don't even need to keep the local copy, which can get outdated, and still not fail the checks.
Well, I'm not fundamentally absolutely against it, but I'd be happier with you using INFO (which is already present) with "test was skipped" in note - especially if you say that it's supposed to be a pass anyway.
The intended semantics of the result values is
PASSED - everything ok, no questions asked
INFO - the same as PASSED for automation purposes, but a yellow flag for human consumers
NEEDS_INSPECTION - treated as FAILED in automation, red flag for human consumers
FAILED - something really went sideways
Jun 30 2017
for future ref, the reasonable way to get around syncing requirements.txt and setup.py is adding:
+ with open('requirements.txt') as fd: + install_requires = [l.strip() for l in fd.readlines() if l.strip() and not l.strip().startswith('#> ... + install_requires=install_requires,
@mjia BTW what exactly is your use-case, and why is installing from repos not OK for you? I'm asking for two reasons
- packaging resultsdb for PyPi is proving to be rather a PITA
- if you actually need to use resultsdb, setup is necessary - like creating the database, for example - since you are going to need to solve this too (probably are right now anyway) is installing from repos (aka another line in that script that you'll have to have to setup resultsdb anyway) a problem?
@mjia, I don't have any fundamental issues with it, apart of the fact that it adds yet another place to store/track deps.
Jun 27 2017
Looks good. I fixed a non-issue lint error and merged the patch. Thanks!
Jun 26 2017
Some minor issues, mostly WRT keeping the new code in the same style as the already existing pieces. My only actual functional issue here is that I'd probably just plain allowed _sort to manipulate submit_time - other fields of the Result object are IMO not really that relevant for custom-sorting, and the "exciting" user data (which I suppose could be more interesting to sort by) is stored in ResultData (and this inaccessible by this patch) anyway.
Jun 20 2017
On top of the failing tests, some of which are really weird, I suggest you investigate/fix ASAP, I have some mostly semantical issues.
this is fine
If the rpm builds/installs and migrations keep working, it's fine with me. Have you tried building/installing the package, and running resultsdb [init_alembic, init_db, upgrade_db] commands? I'm not really sure how this works, but it seems like the script_location is a path that needs to work from the location from which the migration is executed. I can see how this works when you run it from inside the repo, but I'm not sure whether this will be the same for the app installed from the package.
Jun 19 2017
Jun 14 2017
Just fyi - I don't have, and won't have any input, comments on this. Feel free to merge once you decide what you wanna do.
Jun 13 2017
Jun 12 2017
The patch overrides all the buildsteps we use - since we want every step to report on its progress, we ought to change how they behave, base or not. (I'm not sure I understand what you mean, though).
May 26 2017
Who am I to say what works, and what does not :) I guess you tested it with your usecase, so feel free to merge!
May 23 2017
Well, I'm not a huge fan of this - since not all the commands support the --format flag. This will most definitely have the same issues as testcloud does, but if the goal is to really have it now...
May 18 2017
May 16 2017
Looks good for a WIP. My concern here is, that with disposable minions, we do a thing where we use "the right fedora version", so e.g. fc24 packages are tested on F24 machine, and so on. I'd like to see the same for Docker - it can even be done quite easily. Not that it needs to happen for PoC, but I'd like at least a big fat "TODO/FIXME" somewhere in the code to remind you of that :)
Looks good as for a WIP to me. My only real concern here is the broad deletion of all the minion-related code - this might be because I'm not familiar with the design details, but WRT the disposable "minion" - what is the plan for choosing the "right" image for the task (aka using F24 to test F24 packages) that we had in the "previoius" code? Are we dropping the feature alltogether, or is there another process being planned to do that? If so, what is it?
Apr 20 2017
What would be the usual search queries?
Apr 3 2017
I'd like to have the task['repo'] changed to task['git_repo'] for the sake of consistency, but it is not a huge issue. Looks good other than this nitpick.
Mar 30 2017
Apart of the comments below, I'd like to see the testsuite updated to reflect the changes, I don't see how this could pass unittests.
Mar 24 2017
I'd like to see some inline comments, but looks good otherwise
Mar 21 2017
Mar 14 2017
Mar 8 2017
D1150 will need adjustments, but that's a non issue.
Fine with me