12:20 p.m.
As previously discussed, I'm ready to merge my storage (plus other stuff
jlaska's been working on) tests onto master. Doing so will result in
the following being pushed:
52 files changed, 3622 insertions(+), 0 deletions(-)
create mode 100644 hooks/git-post-receive/README
create mode 100644 hooks/git-post-receive/autoqa-git-hook.conf
create mode 100755 hooks/git-post-receive/autoqa-git-hook.wsgi
create mode 100644 hooks/git-post-receive/hook.py
create mode 100755 hooks/git-post-receive/post-receive.sample
create mode 100644 tests/anaconda_checkbot/anaconda_checkbot.py
create mode 100755 tests/anaconda_checkbot/checkbot.sh
create mode 100644 tests/anaconda_checkbot/control
create mode 100644 tests/anaconda_checkbot/control.autoqa
create mode 100644 tests/anaconda_checkbot/mock.cfg.in
create mode 100644 tests/anaconda_storage/README
create mode 100644 tests/anaconda_storage/TODO
create mode 100755 tests/anaconda_storage/anaconda_storage.py
create mode 100644 tests/anaconda_storage/control
create mode 100644 tests/anaconda_storage/control.autoqa
create mode 100644 tests/anaconda_storage/framework/__init__.py
create mode 100644 tests/anaconda_storage/framework/cases/Autopart.py
create mode 100644 tests/anaconda_storage/framework/cases/AutopartFreespace.py
create mode 100644 tests/anaconda_storage/framework/cases/EncryptedAutopart.py
create mode 100644 tests/anaconda_storage/framework/cases/FSOnPartition.py
create mode 100644 tests/anaconda_storage/framework/cases/LVMonRAID0.py
create mode 100644 tests/anaconda_storage/framework/cases/NoSwapLVM.py
create mode 100644 tests/anaconda_storage/framework/cases/RAID0.py
create mode 100644 tests/anaconda_storage/framework/cases/RAID1.py
create mode 100644 tests/anaconda_storage/framework/cases/RAID5.py
create mode 100644 tests/anaconda_storage/framework/cases/RAID6.py
create mode 100644 tests/anaconda_storage/framework/cases/__init__.py
create mode 100755 tests/anaconda_storage/framework/driver.py.in
create mode 100644 tests/anaconda_storage/framework/exception.py
create mode 100644 tests/anaconda_storage/framework/intf.py
create mode 100755 tests/anaconda_storage/framework/runtest.py
create mode 100644 tests/anaconda_storage/framework/storage-test.ks
create mode 100644 tests/anaconda_storage/framework/suites/Autopart.py
create mode 100644 tests/anaconda_storage/framework/suites/AutopartFreespace.py
create mode 100644 tests/anaconda_storage/framework/suites/AutopartPreexistAutopart.py
create mode 100644 tests/anaconda_storage/framework/suites/ConflictingLVMAutopart.py
create mode 100644 tests/anaconda_storage/framework/suites/EncryptedAutopart.py
create mode 100644 tests/anaconda_storage/framework/suites/Ext2OnPartition.py
create mode 100644 tests/anaconda_storage/framework/suites/Ext3OnPartition.py
create mode 100644 tests/anaconda_storage/framework/suites/Ext4OnPartition.py
create mode 100644 tests/anaconda_storage/framework/suites/LVMonRAID0.py
create mode 100644 tests/anaconda_storage/framework/suites/NoSwapLVM.py
create mode 100644 tests/anaconda_storage/framework/suites/RAID0.py
create mode 100644 tests/anaconda_storage/framework/suites/RAID1.py
create mode 100644 tests/anaconda_storage/framework/suites/RAID5.py
create mode 100644 tests/anaconda_storage/framework/suites/RAID6.py
create mode 100644 tests/anaconda_storage/framework/suites/__init__.py
create mode 100644 tests/compose_tree/compose_tree.py
create mode 100755 tests/compose_tree/compose_tree.sh
create mode 100644 tests/compose_tree/control
create mode 100644 tests/compose_tree/control.autoqa
clumens@exeter:~/src/autoqa$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 87 commits.
Everyone's still okay with this, yeah? Because that's a big pile of stuff
to push on everyone all at once.
- Chris
2:10 p.m.
On Wed, 2011-01-05 at 13:20 -0500, Chris Lumens wrote:
As previously discussed, I'm ready to merge my storage (plus
other stuff
jlaska's been working on) tests onto master. Doing so will result in
the following being pushed:
52 files changed, 3622 insertions(+), 0 deletions(-)
create mode 100644 hooks/git-post-receive/README
create mode 100644 hooks/git-post-receive/autoqa-git-hook.conf
create mode 100755 hooks/git-post-receive/autoqa-git-hook.wsgi
create mode 100644 hooks/git-post-receive/hook.py
create mode 100755 hooks/git-post-receive/post-receive.sample
This is new since the last time we reviewed the branch on the list.
I've tried to document as much as possible ahead of time in the README
listed above (see
http://git.fedorahosted.org/git/?p=autoqa.git;a=blob;f=hooks/git-post-rec...).
Just like most everything else in the patchset, this is an addition, and only one new
test is using this hook (see anaconda_checkbot below). So I'm not expecting any
disruption to existing tests.
I'm anxious to see this hook+test in action, but since it's beyond the
original bill of sale for the branch, I definitely welcome discussion
first.
create mode 100644 tests/anaconda_checkbot/anaconda_checkbot.py
create mode 100755 tests/anaconda_checkbot/checkbot.sh
create mode 100644 tests/anaconda_checkbot/control
create mode 100644 tests/anaconda_checkbot/control.autoqa
create mode 100644 tests/anaconda_checkbot/mock.cfg.in
Since last reviewed, some minor bug fixes, and adjusted to only execute
from the git-post-receive watcher. Whenever someone does a `git push`
into upstream anaconda.git, this test will be triggered (it throttles at
10 minutes).
create mode 100644 tests/anaconda_storage/README
create mode 100644 tests/anaconda_storage/TODO
create mode 100755 tests/anaconda_storage/anaconda_storage.py
create mode 100644 tests/anaconda_storage/control
create mode 100644 tests/anaconda_storage/control.autoqa
create mode 100644 tests/anaconda_storage/framework/__init__.py
create mode 100644 tests/anaconda_storage/framework/cases/Autopart.py
create mode 100644 tests/anaconda_storage/framework/cases/AutopartFreespace.py
create mode 100644 tests/anaconda_storage/framework/cases/EncryptedAutopart.py
create mode 100644 tests/anaconda_storage/framework/cases/FSOnPartition.py
create mode 100644 tests/anaconda_storage/framework/cases/LVMonRAID0.py
create mode 100644 tests/anaconda_storage/framework/cases/NoSwapLVM.py
create mode 100644 tests/anaconda_storage/framework/cases/RAID0.py
create mode 100644 tests/anaconda_storage/framework/cases/RAID1.py
create mode 100644 tests/anaconda_storage/framework/cases/RAID5.py
create mode 100644 tests/anaconda_storage/framework/cases/RAID6.py
create mode 100644 tests/anaconda_storage/framework/cases/__init__.py
create mode 100755 tests/anaconda_storage/framework/driver.py.in
create mode 100644 tests/anaconda_storage/framework/exception.py
create mode 100644 tests/anaconda_storage/framework/intf.py
create mode 100755 tests/anaconda_storage/framework/runtest.py
create mode 100644 tests/anaconda_storage/framework/storage-test.ks
create mode 100644 tests/anaconda_storage/framework/suites/Autopart.py
create mode 100644 tests/anaconda_storage/framework/suites/AutopartFreespace.py
create mode 100644 tests/anaconda_storage/framework/suites/AutopartPreexistAutopart.py
create mode 100644 tests/anaconda_storage/framework/suites/ConflictingLVMAutopart.py
create mode 100644 tests/anaconda_storage/framework/suites/EncryptedAutopart.py
create mode 100644 tests/anaconda_storage/framework/suites/Ext2OnPartition.py
create mode 100644 tests/anaconda_storage/framework/suites/Ext3OnPartition.py
create mode 100644 tests/anaconda_storage/framework/suites/Ext4OnPartition.py
create mode 100644 tests/anaconda_storage/framework/suites/LVMonRAID0.py
create mode 100644 tests/anaconda_storage/framework/suites/NoSwapLVM.py
create mode 100644 tests/anaconda_storage/framework/suites/RAID0.py
create mode 100644 tests/anaconda_storage/framework/suites/RAID1.py
create mode 100644 tests/anaconda_storage/framework/suites/RAID5.py
create mode 100644 tests/anaconda_storage/framework/suites/RAID6.py
create mode 100644 tests/anaconda_storage/framework/suites/__init__.py
create mode 100644 tests/compose_tree/compose_tree.py
create mode 100755 tests/compose_tree/compose_tree.sh
create mode 100644 tests/compose_tree/control
create mode 100644 tests/compose_tree/control.autoqa
This is another recent change since last reviewed. The compose_tree
test is initiated by a koji build of the anaconda, pungi or
spin-kickstarts packages. It will do a pungi run in an attempt to
ensure the ISO image creation process works. The goal of the test is to
identify any compose-related issues ahead of time. The procedure used
in the test is documented in more detail at
http://fedoraproject.org/wiki/How_to_build_a_Rawhide_ISO_image_for_testing.
Everyone's still okay with this, yeah? Because that's a big
pile of stuff
to push on everyone all at once.
I don't have issue with it, but I'd like to make sure Kamil and Josef
are still comfortable with the proposed changes.
Thanks,
James
9:47 a.m.
First round of review, just looking at tests/compose_tree for now.
On Monday, I'll try to actually run it :)
control.autoqa:
# The test can be run for post-tree-compose, or post-koji-build
if hook != 'post-koji-build':
execute = False
What about the post-tree-compose? An outdated comment?
compose_tree.py:
try:
out = utils.system_output(cmd, retain_output=True)
except error.CmdError, e:
self.result = 'FAILED'
out = e.result_obj.stdout
else:
self.outputs = out
Maybe 'finally' instead of 'else'?
10:52 a.m.
On Fri, 2011-01-07 at 10:47 -0500, Kamil Paral wrote:
First round of review, just looking at tests/compose_tree for now.
On Monday, I'll try to actually run it :)
> control.autoqa:
> # The test can be run for post-tree-compose, or post-koji-build
> if hook != 'post-koji-build':
> execute = False
What about the post-tree-compose? An outdated comment?
Ah yes, thanks. I'll fix this in the clumens branch
> compose_tree.py:
> try:
> out = utils.system_output(cmd, retain_output=True)
> except error.CmdError, e:
> self.result = 'FAILED'
> out = e.result_obj.stdout
> else:
> self.outputs = out
Maybe 'finally' instead of 'else'?
Possibly, I was just copying from another test there. I can't see any
benefit to using else vs finally here. It seems the big difference is
how exceptions are handled . Any thoughts?
http://docs.python.org/reference/compound_stmts.html#finally
Thanks,
James
2:25 a.m.
----- Original Message -----
On Fri, 2011-01-07 at 10:47 -0500, Kamil Paral wrote:
> First round of review, just looking at tests/compose_tree for now.
> On Monday, I'll try to actually run it :)
>
> > control.autoqa:
> > # The test can be run for post-tree-compose, or post-koji-build
> > if hook != 'post-koji-build':
> > execute = False
>
> What about the post-tree-compose? An outdated comment?
Ah yes, thanks. I'll fix this in the clumens branch
> > compose_tree.py:
> > try:
> > out = utils.system_output(cmd, retain_output=True)
> > except error.CmdError, e:
> > self.result = 'FAILED'
> > out = e.result_obj.stdout
> > else:
> > self.outputs = out
>
> Maybe 'finally' instead of 'else'?
Possibly, I was just copying from another test there. I can't see any
benefit to using else vs finally here. It seems the big difference is
how exceptions are handled . Any thoughts?
http://docs.python.org/reference/compound_stmts.html#finally
Thanks,
James
I suspect we want to have self.outputs always populated, both when
the commands exits properly and when it doesn't exit properly, right?
That means 'finally' is needed there, because 'else' clause is
executed only when no exception occurs.
2:55 p.m.
On Mon, 2011-01-10 at 03:25 -0500, Kamil Paral wrote:
----- Original Message -----
> On Fri, 2011-01-07 at 10:47 -0500, Kamil Paral wrote:
> > First round of review, just looking at tests/compose_tree for now.
> > On Monday, I'll try to actually run it :)
> >
> > > control.autoqa:
> > > # The test can be run for post-tree-compose, or post-koji-build
> > > if hook != 'post-koji-build':
> > > execute = False
> >
> > What about the post-tree-compose? An outdated comment?
>
> Ah yes, thanks. I'll fix this in the clumens branch
>
> > > compose_tree.py:
> > > try:
> > > out = utils.system_output(cmd, retain_output=True)
> > > except error.CmdError, e:
> > > self.result = 'FAILED'
> > > out = e.result_obj.stdout
> > > else:
> > > self.outputs = out
> >
> > Maybe 'finally' instead of 'else'?
>
> Possibly, I was just copying from another test there. I can't see any
> benefit to using else vs finally here. It seems the big difference is
> how exceptions are handled . Any thoughts?
>
> http://docs.python.org/reference/compound_stmts.html#finally
>
> Thanks,
> James
I suspect we want to have self.outputs always populated, both when
the commands exits properly and when it doesn't exit properly, right?
That means 'finally' is needed there, because 'else' clause is
executed only when no exception occurs.
I've pushed several fixes into the clumens branch to address your
feedback.
http://git.fedorahosted.org/git/?p=autoqa.git;a=commitdiff;h=fa03f8ae5eb4...
Thanks,
James
9:08 a.m.
----- Original Message -----
> create mode 100644
tests/anaconda_checkbot/anaconda_checkbot.py
> create mode 100755 tests/anaconda_checkbot/checkbot.sh
> create mode 100644 tests/anaconda_checkbot/control
> create mode 100644 tests/anaconda_checkbot/control.autoqa
> create mode 100644 tests/anaconda_checkbot/mock.cfg.in
Since last reviewed, some minor bug fixes, and adjusted to only
execute
from the git-post-receive watcher. Whenever someone does a `git push`
into upstream anaconda.git, this test will be triggered (it throttles
at
10 minutes).
anaconda_checkbot.py:
assert kwargs['hook'] in ['post-tree-compose',
'git-post-receive'], \
'Unexpected hook argument: %s' % kwargs['hook']
The 'post-tree-compose' is not mentioned in control.autoqa. Do we want
to have it there?
> create mode 100644 hooks/git-post-receive/README
> create mode 100644 hooks/git-post-receive/autoqa-git-hook.conf
> create mode 100755 hooks/git-post-receive/autoqa-git-hook.wsgi
> create mode 100644 hooks/git-post-receive/hook.py
> create mode 100755 hooks/git-post-receive/post-receive.sample
This is new since the last time we reviewed the branch on the list.
I've tried to document as much as possible ahead of time in the README
listed above (see
http://git.fedorahosted.org/git/?p=autoqa.git;a=blob;f=hooks/git-post-rec...).
Just like most everything else in the patchset, this is an addition,
and only one new test is using this hook (see anaconda_checkbot
below). So I'm not expecting any disruption to existing tests.
I'm anxious to see this hook+test in action, but since it's beyond the
original bill of sale for the branch, I definitely welcome discussion
first.
autoqa-git-hook.wsgi:
def index(environ, start_response):
"""This function will be mounted on "/"
"""
start_response('200 OK', [('Content-Type', 'text/html')])
return ['''Thank you, come again.''']
Could you please provide a usage description instead? I have had
a hard time finding out correct arguments.
Also, can it have a dryrun option please? So that it just prints
what it would do, but does not execute anything.
readme:
--url: Git repository URL. The git repository must exist on one of
the git
server specified by git_servers in autoqa.conf
I don't see any changes to autoqa.conf, is this a valid comment?
--branch: the git branch to use (default: master)
If --branch option has a default value, it should be probably listed
amongst optional arguments, not the mandatory ones?
AutoQA tests can expect the following variables from post-koji-build
hook:
Copy-n-paste typo :) ^^^^^^^^^^^^^^^
## Next, enable the post-receive hook
$ cp /usr/share/autoqa/git-post-receive/post-receive.sample hooks/post-receive
./.git/hooks/post-receive ? ^^^^^^^^^^^^^^^^^^
## Adjust the AutoQA WSGI configuration as needed ##
## (/etc/httpd/conf.d/autoqa-git-hook.conf). Information on configuring WSGI
## applications is available at
## http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines
Maybe we could also mention that the wsgi app can be run as a
standard python script (at least for testing purposes)?
All in all, I like the new hook, we will certainly have further uses
for that. Thank you.
Kamil
12:18 p.m.
On Wed, 2011-01-12 at 10:08 -0500, Kamil Paral wrote:
----- Original Message -----
> > create mode 100644 tests/anaconda_checkbot/anaconda_checkbot.py
> > create mode 100755 tests/anaconda_checkbot/checkbot.sh
> > create mode 100644 tests/anaconda_checkbot/control
> > create mode 100644 tests/anaconda_checkbot/control.autoqa
> > create mode 100644 tests/anaconda_checkbot/mock.cfg.in
>
> Since last reviewed, some minor bug fixes, and adjusted to only
> execute
> from the git-post-receive watcher. Whenever someone does a `git push`
> into upstream anaconda.git, this test will be triggered (it throttles
> at
> 10 minutes).
>
anaconda_checkbot.py:
> assert kwargs['hook'] in ['post-tree-compose',
'git-post-receive'], \
> 'Unexpected hook argument: %s' % kwargs['hook']
The 'post-tree-compose' is not mentioned in control.autoqa. Do we want
to have it there?
Before I had the 'git-post-receive' hook completed, 'post-tree-compose'
was the method used to trigger this test. While it's currently only
enabled for 'git-post-receive', I left support for this in the wrapper
for testing purposes. I thought it would be overkill to have it run for
post-tree-compose *and* git-post-receive, but I still liked having
support for post-tree-compose execution if needed.
> > create mode 100644 hooks/git-post-receive/README
> > create mode 100644 hooks/git-post-receive/autoqa-git-hook.conf
> > create mode 100755 hooks/git-post-receive/autoqa-git-hook.wsgi
> > create mode 100644 hooks/git-post-receive/hook.py
> > create mode 100755 hooks/git-post-receive/post-receive.sample
>
> This is new since the last time we reviewed the branch on the list.
> I've tried to document as much as possible ahead of time in the README
> listed above (see
>
http://git.fedorahosted.org/git/?p=autoqa.git;a=blob;f=hooks/git-post-rec...).
> Just like most everything else in the patchset, this is an addition,
> and only one new test is using this hook (see anaconda_checkbot
> below). So I'm not expecting any disruption to existing tests.
>
> I'm anxious to see this hook+test in action, but since it's beyond the
> original bill of sale for the branch, I definitely welcome discussion
> first.
autoqa-git-hook.wsgi:
>def index(environ, start_response):
> """This function will be mounted on "/"
> """
> start_response('200 OK', [('Content-Type',
'text/html')])
> return ['''Thank you, come again.''']
Could you please provide a usage description instead? I have had
a hard time finding out correct arguments.
This isn't intended for humans to run, so I didn't spend a lot of time
on human friendly responses. I also didn't want to worry about html
presentation here. Would it be okay to say something generic like ...
"Consult autoqa documentation for assistance."
and we start documenting our hooks on the wiki?
Also, can it have a dryrun option please? So that it just prints
what it would do, but does not execute anything.
Certainly, I added support for to recognize query string options
'dryrun' or 'dry-run'.
readme:
> --url: Git repository URL. The git repository must exist on one of the git
> server specified by git_servers in autoqa.conf
I don't see any changes to autoqa.conf, is this a valid comment?
It's marked elsewhere in the code with TODO's. I was waiting for the
autoqa.conf code to settle down before adding, and wasn't planning to do
this on the first drop. But it didn't seem to difficult, so I've
adjusted this in my latest fixes.
> --branch: the git branch to use (default: master)
If --branch option has a default value, it should be probably listed
amongst optional arguments, not the mandatory ones?
It is a required parameter, but does provide a default value. I can see
how that might be misleading. I've moved this into optional.
>AutoQA tests can expect the following variables from
post-koji-build hook:
Copy-n-paste typo :) ^^^^^^^^^^^^^^^
Thanks! Fixed.
>## Next, enable the post-receive hook
>$ cp /usr/share/autoqa/git-post-receive/post-receive.sample hooks/post-receive
./.git/hooks/post-receive ? ^^^^^^^^^^^^^^^^^^
>## Adjust the AutoQA WSGI configuration as needed ##
>## (/etc/httpd/conf.d/autoqa-git-hook.conf). Information on configuring WSGI
>## applications is available at
>## http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines
Maybe we could also mention that the wsgi app can be run as a
standard python script (at least for testing purposes)?
Good point, I've added some text to address that.
All in all, I like the new hook, we will certainly have further uses
for that. Thank you.
Thank you for the review comments! I've made several corrections to the
'clumens' branch based on your feedback. Let me know what you think.
http://git.fedorahosted.org/git/?p=autoqa.git;a=commit;h=f0ca4818f73ab933...
Thanks,
James
4:58 a.m.
----- Original Message -----
> autoqa-git-hook.wsgi:
> >def index(environ, start_response):
> > """This function will be mounted on "/"
> > """
> > start_response('200 OK', [('Content-Type',
'text/html')])
> > return ['''Thank you, come again.''']
>
> Could you please provide a usage description instead? I have had
> a hard time finding out correct arguments.
This isn't intended for humans to run, so I didn't spend a lot of time
on human friendly responses. I also didn't want to worry about html
presentation here. Would it be okay to say something generic like ...
"Consult autoqa documentation for assistance."
and we start documenting our hooks on the wiki?
I am not sure if we understand each other. I run the wsgi application
and I had absolutely no idea how to make it work. If it just prints
out a usage message, then it's clear. I.e. when I access localhost:8080,
it could print out (just an example):
'''
Invalid URL. Access this app like:
http://server/git-hook/REPONAME/BRANCHNAME
for running tests for git repo REPONAME and git branch BRANCHNAME.
Example:
http://server/git-hook/anaconda.git/master
Optional arguments (used in the query string):
dryrun: do not execute, just print out commands
'''
Then I immediately know how to use this app. I have used similar
approach for my 'aqc' tool:
http://git.fedorahosted.org/git/?p=autoqa.git;a=blob;f=utils/aqc-ks/aqc-k...
(line 15)
> >## Next, enable the post-receive hook
> >$ cp /usr/share/autoqa/git-post-receive/post-receive.sample
> >hooks/post-receive
> ./.git/hooks/post-receive ? ^^^^^^^^^^^^^^^^^^
>
This one maybe went unnoticed, is the destination dir correct (missing .git/ prefix?)
Thank you for the review comments! I've made several corrections to
the
'clumens' branch based on your feedback. Let me know what you think.
http://git.fedorahosted.org/git/?p=autoqa.git;a=commit;h=f0ca4818f73ab933...
Quoting from the patch:
+ # XXX: should we escape the URLs?
I am almost sure
we don't have to, since we don't run
it through bash (which is the source of escaping requirements),
but run it directly as a system command.
Escaping would be needed, if you run Popen with shell=True, AFAIK.
8:51 a.m.
On Thu, 2011-01-13 at 05:58 -0500, Kamil Paral wrote:
----- Original Message -----
> > autoqa-git-hook.wsgi:
> > >def index(environ, start_response):
> > > """This function will be mounted on "/"
> > > """
> > > start_response('200 OK', [('Content-Type',
'text/html')])
> > > return ['''Thank you, come again.''']
> >
> > Could you please provide a usage description instead? I have had
> > a hard time finding out correct arguments.
>
> This isn't intended for humans to run, so I didn't spend a lot of time
> on human friendly responses. I also didn't want to worry about html
> presentation here. Would it be okay to say something generic like ...
>
> "Consult autoqa documentation for assistance."
>
> and we start documenting our hooks on the wiki?
I am not sure if we understand each other. I run the wsgi application
and I had absolutely no idea how to make it work. If it just prints
out a usage message, then it's clear. I.e. when I access localhost:8080,
it could print out (just an example):
'''
Invalid URL. Access this app like:
http://server/git-hook/REPONAME/BRANCHNAME
for running tests for git repo REPONAME and git branch BRANCHNAME.
Example:
http://server/git-hook/anaconda.git/master
Optional arguments (used in the query string):
dryrun: do not execute, just print out commands
'''
I think I understood, I was just being lazy and not wanting people to
interact with the wsgi application. Also, I wanted to avoid having to
write much HTML in the wsgi response, but what you've listed above isn't
bad. I'll just wrap it in <pre> tags so it formats as expected (or
change the response to 'text/plain'. Thanks for the suggestion.
Then I immediately know how to use this app. I have used similar
approach for my 'aqc' tool:
http://git.fedorahosted.org/git/?p=autoqa.git;a=blob;f=utils/aqc-ks/aqc-k...
(line 15)
> > >## Next, enable the post-receive hook
> > >$ cp /usr/share/autoqa/git-post-receive/post-receive.sample
> > >hooks/post-receive
> > ./.git/hooks/post-receive ? ^^^^^^^^^^^^^^^^^^
> >
This one maybe went unnoticed, is the destination dir correct
(missing .git/ prefix?)
That's okay. For local checkouts of a repo the administrative directory
is .git. But for a git repo created using --bare (noted a few steps
above), there are no files, it's really just all the metadata that
normally exists in .git. You can try it out locally by doing `git clone
--bare myrepo.git`.
--bare
Make a bare GIT repository. That is, instead of creating
<directory> and placing the administrative files in
<directory>/.git, make the <directory> itself the $GIT_DIR.
This
obviously implies the -n because there is nowhere to check
out the
working tree. Also the branch heads at the remote are copied
directly to corresponding local branch heads, without mapping
them
to refs/remotes/origin/. When this option is used, neither
remote-tracking branches nor the related configuration
variables
are created.
>
> Thank you for the review comments! I've made several corrections to
> the
> 'clumens' branch based on your feedback. Let me know what you think.
>
>
http://git.fedorahosted.org/git/?p=autoqa.git;a=commit;h=f0ca4818f73ab933...
Quoting from the patch:
> + # XXX: should we escape the URLs?
I am almost sure we don't have to, since we don't run
it through bash (which is the source of escaping requirements),
but run it directly as a system command.
Escaping would be needed, if you run Popen with shell=True, AFAIK.
Great, good to know.
I've correct the issue above, and pushed the changes into the 'clumens'
branch.
http://git.fedorahosted.org/git/?p=autoqa.git;a=commitdiff;h=9d3fff350d8c...
Thanks,
James
9:50 a.m.
----- Original Message -----
I've correct the issue above, and pushed the changes into the
'clumens'
branch.
http://git.fedorahosted.org/git/?p=autoqa.git;a=commitdiff;h=9d3fff350d8c...
Thanks,
James
Great, /me says ACK :) If you feel it's ready, please merge.
4893
days inactive
4901
days old
autoqa-devel@lists.fedorahosted.org
13 comments
3 participants
participants (3)
-
Chris Lumens -
James Laska -
Kamil Paral