This kept falling off my TODO list, but I finally got what I have for initial mock Fedora infrastructure code up on github:
On Thu, 28 Jul 2011 11:45:36 -0600 Tim Flink tflink@redhat.com wrote:
This kept falling off my TODO list, but I finally got what I have for initial mock Fedora infrastructure code up on github:
Yay for sending emails by accident after typing the first sentence!
Anyways, the code is up on github: - https://github.com/tflink/mock_fedorainfra
As a warning, the code is _VERY_ rough right now - barely enough to be called a proof of concept. Not much in the way of documentation and everything is static right now - queries on any package will always return the same information.
I know that John was interested in working on this and I don't know if he had started or not but figured that this code might be useful. I can add documentation, clean the stuff and give explanations if desired.
Tim
---------------------------------------- Date: Thu, 28 Jul 2011 11:49:53 -0600 From: tflink@redhat.com To: autoqa-devel@lists.fedorahosted.org Subject: Re: Very Rough Code for Mock Fedora Infrastructure
On Thu, 28 Jul 2011 11:45:36 -0600 Tim Flink tflink@redhat.com wrote:
This kept falling off my TODO list, but I finally got what I have for initial mock Fedora infrastructure code up on github:
Yay for sending emails by accident after typing the first sentence!
Anyways, the code is up on github:
As a warning, the code is _VERY_ rough right now - barely enough to be called a proof of concept. Not much in the way of documentation and everything is static right now - queries on any package will always return the same information.
I know that John was interested in working on this and I don't know if he had started or not but figured that this code might be useful. I can add documentation, clean the stuff and give explanations if desired.
Tim
Hey, Tim Thanks much for this. I had indeed done some work on the actual mockups, but so far most of my work so far has been in setting up the actual tests; it looks like that code could be easily integrated with what you've got to create a final project. I'll go through it today and get it presentable and try to get it on Review Board by early this evening. It looks like my code would replace your pytests.sh script.
In a nutshell, it creates the virtual environment, loads up mock Koji and mock Bodhi (I hadn't finished with these, I'll change the code to point to your work) and populates mock Koji and Bodhi with sets of test packages chosen to give specific results from AutoQA depending on the actual test cases. It then compares that output from AutoQA to what is expected and reports on inconsistencies. No report means everything is hunky dory. It then proceeds to the next test listed in the file. When it's all done, it spits out a log of passed and failed tests.
I chose to go with a batch style setup because I figured that this would be a good start it and ignore it until its done situation.
Like I said, I'll try my best to get things ready by this evening; Monday at the latest.
John.
On Fri, 29 Jul 2011 10:06:36 -0400 John Dulaney jdulaney@fedoraproject.org wrote:
Hey, Tim Thanks much for this. I had indeed done some work on the actual mockups, but so far most of my work so far has been in setting up the actual tests; it looks like that code could be easily integrated with what you've got to create a final project. I'll go through it today and get it presentable and try to get it on Review Board by early this evening. It looks like my code would replace your pytests.sh script.
Sorry, I dropped the ball on getting the use case conversation started. I'll get that done shortly.
Assuming that I understand you correctly, I don't see how the runtests.sh script would be completely replaced. That script was designed to setup and run tests on the mock infrastructure itself - not AutoQA. I think I understand what you meant, though.
In a nutshell, it creates the virtual environment, loads up mock Koji and mock Bodhi (I hadn't finished with these, I'll change the code to point to your work) and populates mock Koji and Bodhi with sets of test packages chosen to give specific results from AutoQA depending on the actual test cases. It then compares that output from AutoQA to what is expected and reports on inconsistencies. No report means everything is hunky dory. It then proceeds to the next test listed in the file. When it's all done, it spits out a log of passed and failed tests.
Sounds good to me. Let me know if you want more of the mock interface fleshed out. I'm happy to help.
I chose to go with a batch style setup because I figured that this would be a good start it and ignore it until its done situation.
Like I said, I'll try my best to get things ready by this evening; Monday at the latest.
Cool, good to hear. If you want commit access to that github repo, let me know. Forking it or putting the code elsewhere or anything else you had in mind would also work.
I don't think that you'll be able to use review board unless it knows about the project and it sounds like what you've been working on is separate from the autoqa repo.
I'm looking forward to seeing what you've put together.
Tim
Cool, good to hear. If you want commit access to that github repo, let me know. Forking it or putting the code elsewhere or anything else you had in mind would also work.
I do believe that commit access to that particular Github repo would be the easiest solution. I've made a few modification to your code in order to get everything playing nicely, so that would need to be added, as well.
As soon as I get commit access, I'll commit everything and you can check it out. I've documented how to set up tests, as well as how to get everything running. I wonder if I should document anything else?
John.
Cool, good to hear. If you want commit access to that github repo, let me know. Forking it or putting the code elsewhere or anything else you had in mind would also work.
I do believe that commit access to that particular Github repo would be the easiest solution. I've made a few modification to your code in order to get everything playing nicely, so that would need to be added, as well.
Hi, just use the integrated "fork" feature of GitHub. You can fork any project, make some changes, and the owner can then easily merge them into his code.
On Mon, 1 Aug 2011 05:59:52 -0400 (EDT) Kamil Paral kparal@redhat.com wrote:
Cool, good to hear. If you want commit access to that github repo, let me know. Forking it or putting the code elsewhere or anything else you had in mind would also work.
I do believe that commit access to that particular Github repo would be the easiest solution. I've made a few modification to your code in order to get everything playing nicely, so that would need to be added, as well.
Hi, just use the integrated "fork" feature of GitHub. You can fork any project, make some changes, and the owner can then easily merge them into his code.
I'm fine with either.
John, if you want to just commit to the same repo - let me know what your github username is and I can add you.
Tim
autoqa-devel@lists.fedorahosted.org
-
John Dulaney -
John Dulaney -
Kamil Paral -
Tim Flink