Re: Review Board 1.7 RC 1 is released!
Review Board 1.7 requires Python 2.5 or higher. You'll have to upgrade in
order for it to work.
What I'd recommend is a newer CentOS install, since some of our
dependencies will also need to be updated, and you won't hit as many issues
with the upgrade. Your best bet is to upgrade to something with Python 2.7.
Christian
--
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com
On Wed, Dec 5, 2012 at 2:22 AM, Vishal Gautam gautamvis...@gmail.comwrote:
We are trying out RB, we have 1.6.14 installed and running on CentOS 5.5.
Tried to upgrade it to 1.7 using following cmd but its failing ...
easy_install -f
http://downloads.reviewboard.org/releases/ReviewBoard/1.7 -U ReviewBoard
Here is the stracktrace, any help will be much appreciated
Best match: ReviewBoard 1.7rc1
Downloading
http://downloads.reviewboard.org/releases/ReviewBoard/1.7/ReviewBoard-1.7rc1.tar.gz
Processing ReviewBoard-1.7rc1.tar.gz
Running ReviewBoard-1.7rc1/setup.py -q bdist_egg --dist-dir
/tmp/easy_install-vW-lSE/ReviewBoard-1.7rc1/egg-dist-tmp-DrI1Td
Traceback (most recent call last):
File ./contrib/internal/build-media.py, line 19, in ?
ret = call_command('collectstatic', interactive=False, verbosity=2)
File
/usr/lib/python2.4/site-packages/Django-1.3.4-py2.4.egg/django/core/management/__init__.py,
line 153, in call_command
klass = load_command_class(app_name, name)
File
/usr/lib/python2.4/site-packages/Django-1.3.4-py2.4.egg/django/core/management/__init__.py,
line 68, in load_command_class
return module.Command()
File
/usr/lib/python2.4/site-packages/Django-1.3.4-py2.4.egg/django/contrib/staticfiles/management/commands/collectstatic.py,
line 41, in __init__
self.storage = get_storage_class(settings.STATICFILES_STORAGE)()
File
/usr/lib/python2.4/site-packages/Django-1.3.4-py2.4.egg/django/core/files/storage.py,
line 265, in get_storage_class
raise ImproperlyConfigured('Error importing storage module %s: %s' %
(module, e))
django.core.exceptions.ImproperlyConfigured: Error importing storage
module pipeline.storage: cannot import name CachedFilesMixin
Traceback (most recent call last):
File /usr/bin/easy_install, line 7, in ?
sys.exit(
File
/usr/lib/python2.4/site-packages/setuptools-0.6c12dev_r88846-py2.4.egg/setuptools/command/easy_install.py,
line 1712, in main
..
snipped
...
self.distribution.run_command(command)
File /usr/lib64/python2.4/distutils/dist.py, line 966, in run_command
cmd_obj.run()
File setup.py, line 63, in run
File /usr/lib64/python2.4/distutils/cmd.py, line 333, in run_command
self.distribution.run_command(command)
File /usr/lib64/python2.4/distutils/dist.py, line 966, in run_command
cmd_obj.run()
File setup.py, line 81, in run
RuntimeError: Failed to build media files
On Friday, November 30, 2012 3:38:07 AM UTC+5:30, Christian Hammond wrote:
Review Board Better Late Than Never 1.7 RC 1 is out. We had hoped to
get this out earlier, but hit some problems and annoyances during some
production use that we felt should be fixed first. So trust me, it was
worth the wait :)
There's a lot of fixes, enhancements, and some small extension interface
changes in this release.
See the news and release notes for more information.
http://www.reviewboard.org/**news/2012/11/29/review-board-**
1-7-rc-1-released/http://www.reviewboard.org/news/2012/11/29/review-board-1-7-rc-1-released/
We'd like to ask those who plan to upgrade to 1.7 to please give it a
try. Aside from major fixes, we are hoping there won't be many changes made
until the final 1.7, so now's the time to report any regressions you hit.
Christian
--
Christian Hammond - chi...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com
--
Want to help the Review Board project? Donate today at
http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~--~~~~--~~--~--~---
To unsubscribe from this group, send email to
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/reviewboard?hl=en
Info per source file
Hi, Is it possible to get info (e.g. fetch from database) if a particular source file (or at least diffset) was reviewed? I can see filelists in the table diffviewer_filediff, but I'm unable to find the connection to the status or to the request id (e.g. table reviews_review). I use RB 1.7 RC1. Laimonas -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en
Re: Info per source file
Hi, Are you looking to do this through the web API, or are you writing an extension or something? I'm gathering the latter. I'm not at the computer so I don't have the code in front of me, but you can do something like filediff.comments to get the Django relation to the diff comments for the file. You can also do Review.objects.filter(comments__filediff=filediff) or similar to get the reviews commenting on a file. If you're stuck and those don't work, I'll send some working sample code later. Christian On Dec 5, 2012, at 6:50, Laimonas Mockus laimonas.moc...@gmail.com wrote: Hi, Is it possible to get info (e.g. fetch from database) if a particular source file (or at least diffset) was reviewed? I can see filelists in the table diffviewer_filediff, but I'm unable to find the connection to the status or to the request id (e.g. table reviews_review). I use RB 1.7 RC1. Laimonas -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en
Issues publishing review with ReviewBoard
Hello All,
I've been racking my brain on this for a couple of days and figured I'd
post here before I refactor my entire setup. Basically what we are doing
is, we have two servers - one is a standard apache web node that acts as a
proxy server and terminates SSL, then we have reviewboard being proxied
behind that.
I've got everything setup and working with the exception of one piece. I
can upload a diff, I can add titles, descriptions, reviewers, etc. Tracing
the requests I can see that https is being returned as the request URL,
HOWEVER, when you go to publish a review, we get a 304 error and the
request URL is a non-https link.
I'm doing the rewriting from the web node directly, with a mod_rewrite
specifically calling out that its proxied (but changing or completely
removing the options doesn't make any difference) For reference, here's the
rewrite ::
RewriteCond %{HTTPS} off
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R=301,P,PT,L]
When I click on publish, essentially I see two requests (and nothing at all
in the debug logs, etc) The first ::
Request URL:*
https://reviewboard.boku.com/reviews/api/review-requests/189/?api_format=json
*
Request Method:GET
Status Code:304 NOT MODIFIED
Request Headersview source
Accept:application/json, text/javascript, */*
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Cookie:rbsessionid=bbf077166394571eaaf514053e6c4691;
__utma=109258518.568604164.1352840613.1352938162.1354736370.4;
__utmc=109258518; __utmz=109258518.1352929269.2.2.utmcsr=google|utmccn=(
organic)|utmcmd=organic|utmctr=(not%20provided); csrftoken=
b6dec71b9219e2090d9d98acf203e1f4
Host:reviewboard.boku.com
If-Modified-Since:Wed, 05 Dec 2012 22:02:11 GMT
Referer:https://reviewboard.boku.com/reviews/r/189/
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5)
AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.95 Safari/537.11
X-Requested-With:XMLHttpRequest
Query String Parametersview URL encoded
api_format:json
Response Headersview source
Cache-Control:max-age=0
Connection:close
Date:Thu, 06 Dec 2012 00:12:46 GMT
Expires:Thu, 06 Dec 2012 00:12:48 GMT
Server:Apache/2.2.15 (CentOS)
Vary:Accept,Cookie,Accept-Language
The second ::
Request URL:*
http://reviewboard.boku.com/reviews/api/review-requests/189/draft/*
Request Method:OPTIONS
Status Code:200 OK
Request Headersview source
Accept:*/*
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Access-Control-Request-Headers:origin, x-requested-with, content-type,
accept
Access-Control-Request-Method:PUT
Connection:keep-alive
Host:reviewboard.boku.com
Origin:https://reviewboard.boku.com
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5)
AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.95 Safari/537.11
Response Headersview source
Allow:GET,HEAD,POST,OPTIONS
Connection:close
Content-Length:0
Content-Type:text/plain; charset=UTF-8
Date:Thu, 06 Dec 2012 00:12:48 GMT
Server:Apache
literally every other request comes in via HTTPS, clicking on links,
performing actions, etc. the ONLY thing that fails is publishing. I'm not
sure what to do next at this point so I wanted to see if anyone had ever
run into this. Below I will also paste the apache config for the proxy/ssl
term server and the web head for comparison.
SSL Proxy ::
VirtualHost 192.168.200.124:443
ServerName reviewboard.COMPANYNAME.comhttp://reviewboard.companyname.com/
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
SSLCertificateFile /etc/pki/entrust-certs/
star.COMPANYNAME.com/star.COMPANYNAME.com.crthttp://star.companyname.com/star.COMPANYNAME.com.crt
SSLCertificateKeyFile /etc/pki/entrust-certs/
star.COMPANYNAME.com/star.COMPANYNAME.com.keyhttp://star.companyname.com/star.COMPANYNAME.com.key
SSLCACertificateFile /etc/pki/entrust-certs/
star.COMPANYNAME.com/star.COMPANYNAME.com_bundle.crthttp://star.companyname.com/star.COMPANYNAME.com_bundle.crt
# SSLCertificateFile /etc/pki/tls/certs/COMPANYNAME.com.crt
# SSLCertificateKeyFile /etc/pki/tls/certs/COMPANYNAME.com.key
# SSLCACertificateFile /etc/pki/tls/certs/gd_bundle.crt
# Default to not cache anything
ExpiresActive On
ExpiresDefault access plus 0 seconds
# Cache just images
ExpiresByType image/gif access plus 10 minutes
ExpiresByType image/jpg access plus 10 minutes
ExpiresByType image/png access plus 10 minutes
proxyPreserveHost On
ProxyRequests On
ProxyPass /
http://reviewboard01.local-COMPANYNAME.net:8080/http://reviewboard01.local-companyname.net:8080/
ProxyPassReverse /
http://reviewboard01.local-COMPANYNAME.net:8080/http://reviewboard01.local-companyname.net:8080/
Location /
ProxyPassReverse /
Order deny,allow
Allow from all
/Location
RequestHeader edit Location
Re: Issues publishing review with ReviewBoard
Hi Brian,
Something to try would be to add:
os.environ['HTTPS'] = 'on'
to htdocs/reviewboard.wsgi.
See if that makes a difference. I noticed this at one point as well. We
need to change things to generate this by default if using https, or find a
beter way to turn it on by default.
Christian
--
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com
On Wed, Dec 5, 2012 at 4:31 PM, Brian Lewis *@brianlewis.us wrote:
Hello All,
I've been racking my brain on this for a couple of days and figured I'd
post here before I refactor my entire setup. Basically what we are doing
is, we have two servers - one is a standard apache web node that acts as a
proxy server and terminates SSL, then we have reviewboard being proxied
behind that.
I've got everything setup and working with the exception of one piece. I
can upload a diff, I can add titles, descriptions, reviewers, etc. Tracing
the requests I can see that https is being returned as the request URL,
HOWEVER, when you go to publish a review, we get a 304 error and the
request URL is a non-https link.
I'm doing the rewriting from the web node directly, with a mod_rewrite
specifically calling out that its proxied (but changing or completely
removing the options doesn't make any difference) For reference, here's the
rewrite ::
RewriteCond %{HTTPS} off
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_**URI} [R=301,P,PT,L]
When I click on publish, essentially I see two requests (and nothing at
all in the debug logs, etc) The first ::
Request URL:*https://reviewboard.boku.com/reviews/api/review-
requests/189/?api_format=json*
Request Method:GET
Status Code:304 NOT MODIFIED
Request Headersview source
Accept:application/json, text/javascript, */*
Accept-Charset:ISO-8859-1,utf-**8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,**sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Cookie:rbsessionid=**bbf077166394571eaaf514053e6c46**91;
__utma=109258518.568604164.**1352840613.1352938162.**1354736370.4;
__utmc=109258518; __utmz=109258518.1352929269.2.**2.utmcsr=google|utmccn=(
**organic)|utmcmd=organic|**utmctr=(not%20provided); csrftoken=**
b6dec71b9219e2090d9d98acf203e1**f4
Host:reviewboard.boku.com
If-Modified-Since:Wed, 05 Dec 2012 22:02:11 GMT
Referer:https://reviewboard.**boku.com/reviews/r/189/https://reviewboard.boku.com/reviews/r/189/
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5)
AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.95 Safari/537.11
X-Requested-With:**XMLHttpRequest
Query String Parametersview URL encoded
api_format:json
Response Headersview source
Cache-Control:max-age=0
Connection:close
Date:Thu, 06 Dec 2012 00:12:46 GMT
Expires:Thu, 06 Dec 2012 00:12:48 GMT
Server:Apache/2.2.15 (CentOS)
Vary:Accept,Cookie,Accept-**Language
The second ::
Request URL:*http://reviewboard.boku.com/reviews/api/review-
requests/189/draft/*
Request Method:OPTIONS
Status Code:200 OK
Request Headersview source
Accept:*/*
Accept-Charset:ISO-8859-1,utf-**8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,**sdch
Accept-Language:en-US,en;q=0.8
Access-Control-Request-**Headers:origin, x-requested-with, content-type,
accept
Access-Control-Request-Method:**PUT
Connection:keep-alive
Host:reviewboard.boku.com
Origin:https://reviewboard.**boku.com https://reviewboard.boku.com/
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5)
AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.95 Safari/537.11
Response Headersview source
Allow:GET,HEAD,POST,OPTIONS
Connection:close
Content-Length:0
Content-Type:text/plain; charset=UTF-8
Date:Thu, 06 Dec 2012 00:12:48 GMT
Server:Apache
literally every other request comes in via HTTPS, clicking on links,
performing actions, etc. the ONLY thing that fails is publishing. I'm not
sure what to do next at this point so I wanted to see if anyone had ever
run into this. Below I will also paste the apache config for the proxy/ssl
term server and the web head for comparison.
SSL Proxy ::
VirtualHost 192.168.200.124:443
ServerName reviewboard.COMPANYNAME.comhttp://reviewboard.companyname.com/
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+**RSA:+HIGH:+MEDIUM:+LOW
SSLCertificateFile /etc/pki/entrust-certs/star.**COMPANYNAME.com/star.**
COMPANYNAME.com.crt http://star.companyname.com/star.COMPANYNAME.com.crt
SSLCertificateKeyFile /etc/pki/entrust-certs/star.**
COMPANYNAME.com/star.**COMPANYNAME.com.keyhttp://star.companyname.com/star.COMPANYNAME.com.key
SSLCACertificateFile /etc/pki/entrust-certs/star.**COMPANYNAME.com/star.
**COMPANYNAME.com_bundle.crthttp://star.companyname.com/star.COMPANYNAME.com_bundle.crt
# SSLCertificateFile /etc/pki/tls/certs/**COMPANYNAME.com.crt
# SSLCertificateKeyFile /etc/pki/tls/certs/**COMPANYNAME.com.key
# SSLCACertificateFile
Re: Issues publishing review with ReviewBoard
Hi Christian,
Just tried that and there's no change. Additionally, I notice the response
from the first request looks like this (notice the http URL's vs https..
almost like it sees the redirect but doesn't want to follow it!)
{stat: ok, review_request: {status: pending, last_updated:
2012-12-05 14:02:11, description: , links: {diffs: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/diffs/;,
method: GET}, repository: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/repositories/3/;, method:
GET, title: Puppet}, screenshots: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/screenshots/;,
method: GET}, self: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/;,
method: GET}, update: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/;,
method: PUT}, last_update: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/last-update/;,
method: GET}, reviews: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/reviews/;,
method: GET}, draft: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/draft/;,
method: GET}, file_attachments: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/file-attachments/;,
method: GET}, submitter: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/users/admin/;, method:
GET, title: admin}, changes: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/changes/;,
method: GET}, delete: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/;,
method: DELETE}}, public: false, target_groups: [], bugs_closed:
[], changenum: null, target_people: [], testing_done: , branch:
, time_added: 2012-12-05 14:02:11, summary: , id: 189}}
On Wednesday, December 5, 2012 4:38:51 PM UTC-8, Christian Hammond wrote:
Hi Brian,
Something to try would be to add:
os.environ['HTTPS'] = 'on'
to htdocs/reviewboard.wsgi.
See if that makes a difference. I noticed this at one point as well. We
need to change things to generate this by default if using https, or find a
beter way to turn it on by default.
Christian
--
Christian Hammond - chi...@chipx86.com javascript:
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com
On Wed, Dec 5, 2012 at 4:31 PM, Brian Lewis *...@brianlewis.usjavascript:
wrote:
Hello All,
I've been racking my brain on this for a couple of days and figured I'd
post here before I refactor my entire setup. Basically what we are doing
is, we have two servers - one is a standard apache web node that acts as a
proxy server and terminates SSL, then we have reviewboard being proxied
behind that.
I've got everything setup and working with the exception of one piece. I
can upload a diff, I can add titles, descriptions, reviewers, etc. Tracing
the requests I can see that https is being returned as the request URL,
HOWEVER, when you go to publish a review, we get a 304 error and the
request URL is a non-https link.
I'm doing the rewriting from the web node directly, with a mod_rewrite
specifically calling out that its proxied (but changing or completely
removing the options doesn't make any difference) For reference, here's the
rewrite ::
RewriteCond %{HTTPS} off
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_**URI} [R=301,P,PT,L]
When I click on publish, essentially I see two requests (and nothing at
all in the debug logs, etc) The first ::
Request URL:*https://reviewboard.boku.com/reviews/api/review-
requests/189/?api_format=json*
Request Method:GET
Status Code:304 NOT MODIFIED
Request Headersview source
Accept:application/json, text/javascript, */*
Accept-Charset:ISO-8859-1,utf-**8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,**sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Cookie:rbsessionid=**bbf077166394571eaaf514053e6c46**91;
__utma=109258518.568604164.**1352840613.1352938162.**1354736370.4;
__utmc=109258518; __utmz=109258518.1352929269.2.**
2.utmcsr=google|utmccn=(**organic)|utmcmd=organic|**utmctr=(not%20provided);
csrftoken=**b6dec71b9219e2090d9d98acf203e1**f4
Host:reviewboard.boku.com
If-Modified-Since:Wed, 05 Dec 2012 22:02:11 GMT
Referer:https://reviewboard.**boku.com/reviews/r/189/https://reviewboard.boku.com/reviews/r/189/
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5)
AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.95 Safari/537.11
X-Requested-With:**XMLHttpRequest
Query String Parametersview URL encoded
api_format:json
Response Headersview source
Cache-Control:max-age=0
Connection:close
Date:Thu, 06 Dec 2012 00:12:46 GMT
Expires:Thu, 06 Dec 2012 00:12:48 GMT
Server:Apache/2.2.15 (CentOS)
Vary:Accept,Cookie,Accept-**Language
The second ::
Request URL:*http://reviewboard.boku.com/reviews/api/review-
requests/189/draft/*
Request
Re: Issues publishing review with ReviewBoard
Just to sanity check, did you reload Apache?
We put in absolute URLs, and we tell Django to build those for us. Django
will insert https if it sees the HTTPS environment variable set to
on, and http otherwise. Provided the process is ending up with this
environment variable set, and the server is reloaded, it should be working.
Would you mind pasting the reviewboard.wsgi file?
Christian
--
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com
On Wed, Dec 5, 2012 at 4:46 PM, Brian Lewis *@brianlewis.us wrote:
Hi Christian,
Just tried that and there's no change. Additionally, I notice the response
from the first request looks like this (notice the http URL's vs https..
almost like it sees the redirect but doesn't want to follow it!)
{stat: ok, review_request: {status: pending, last_updated:
2012-12-05 14:02:11, description: , links: {diffs: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/diffs/;,
method: GET}, repository: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/repositories/3/;,
method: GET, title: Puppet}, screenshots: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/screenshots/;,
method: GET}, self: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/;,
method: GET}, update: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/;,
method: PUT}, last_update: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/last-update/;,
method: GET}, reviews: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/reviews/;,
method: GET}, draft: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/draft/;,
method: GET}, file_attachments: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/file-attachments/;,
method: GET}, submitter: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/users/admin/;, method:
GET, title: admin}, changes: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/changes/;,
method: GET}, delete: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/;,
method: DELETE}}, public: false, target_groups: [], bugs_closed:
[], changenum: null, target_people: [], testing_done: , branch:
, time_added: 2012-12-05 14:02:11, summary: , id: 189}}
On Wednesday, December 5, 2012 4:38:51 PM UTC-8, Christian Hammond wrote:
Hi Brian,
Something to try would be to add:
os.environ['HTTPS'] = 'on'
to htdocs/reviewboard.wsgi.
See if that makes a difference. I noticed this at one point as well. We
need to change things to generate this by default if using https, or find a
beter way to turn it on by default.
Christian
--
Christian Hammond - chi...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com
On Wed, Dec 5, 2012 at 4:31 PM, Brian Lewis *...@brianlewis.us wrote:
Hello All,
I've been racking my brain on this for a couple of days and figured I'd
post here before I refactor my entire setup. Basically what we are doing
is, we have two servers - one is a standard apache web node that acts as a
proxy server and terminates SSL, then we have reviewboard being proxied
behind that.
I've got everything setup and working with the exception of one piece. I
can upload a diff, I can add titles, descriptions, reviewers, etc. Tracing
the requests I can see that https is being returned as the request URL,
HOWEVER, when you go to publish a review, we get a 304 error and the
request URL is a non-https link.
I'm doing the rewriting from the web node directly, with a mod_rewrite
specifically calling out that its proxied (but changing or completely
removing the options doesn't make any difference) For reference, here's the
rewrite ::
RewriteCond %{HTTPS} off
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R=301,P,PT,L]
When I click on publish, essentially I see two requests (and nothing at
all in the debug logs, etc) The first ::
Request URL:*https://reviewboard.boku.com/reviews/api/review-requests
/189/?api_format=json*
Request Method:GET
Status Code:304 NOT MODIFIED
Request Headersview source
Accept:application/json, text/javascript, */*
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,**s**dch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Cookie:rbsessionid=**bbf07716639**4571eaaf514053e6c46**91;
__utma=109258518.568604164.**135**2840613.1352938162.**1354736370.**4;
__utmc=109258518; __utmz=109258518.1352929269.2.
2.utmcsr=google|utmccn=(**organi**c)|utmcmd=organic|**utmctr=(not%**20provided);
csrftoken=**b6dec71b9219e2090d9d**98acf203e1**f4
Host:reviewboard.boku.com
If-Modified-Since:Wed, 05 Dec 2012 22:02:11 GMT
Re: Issues publishing review with ReviewBoard
Hi Christian,
Yes - I just stopped apache and manually restarted it as well just to make
sure. Here's a copy of the reviewboard.wsgi file ::
import os
import sys
os.environ['DJANGO_SETTINGS_MODULE'] = reviewboard.settings
os.environ['PYTHON_EGG_CACHE'] = /var/www/reviewboard/tmp/egg_cache
os.environ['HOME'] = /var/www/reviewboard/data
os.environ['HTTPS'] = 'on'
sys.path = ['/var/www/reviewboard/conf'] + sys.path
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
On Wednesday, December 5, 2012 4:52:12 PM UTC-8, Christian Hammond wrote:
Just to sanity check, did you reload Apache?
We put in absolute URLs, and we tell Django to build those for us. Django
will insert https if it sees the HTTPS environment variable set to
on, and http otherwise. Provided the process is ending up with this
environment variable set, and the server is reloaded, it should be working.
Would you mind pasting the reviewboard.wsgi file?
Christian
--
Christian Hammond - chi...@chipx86.com javascript:
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com
On Wed, Dec 5, 2012 at 4:46 PM, Brian Lewis *...@brianlewis.usjavascript:
wrote:
Hi Christian,
Just tried that and there's no change. Additionally, I notice the
response from the first request looks like this (notice the http URL's vs
https.. almost like it sees the redirect but doesn't want to follow it!)
{stat: ok, review_request: {status: pending, last_updated:
2012-12-05 14:02:11, description: , links: {diffs: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/diffs/;,
method: GET}, repository: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/repositories/3/;,
method: GET, title: Puppet}, screenshots: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/screenshots/;,
method: GET}, self: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/;,
method: GET}, update: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/;,
method: PUT}, last_update: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/last-update/;,
method: GET}, reviews: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/reviews/;,
method: GET}, draft: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/draft/;,
method: GET}, file_attachments: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/file-attachments/;,
method: GET}, submitter: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/users/admin/;, method:
GET, title: admin}, changes: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/changes/;,
method: GET}, delete: {href:
http://reviewboard.COMPANYNAME.com/reviews/api/review-requests/189/;,
method: DELETE}}, public: false, target_groups: [], bugs_closed:
[], changenum: null, target_people: [], testing_done: , branch:
, time_added: 2012-12-05 14:02:11, summary: , id: 189}}
On Wednesday, December 5, 2012 4:38:51 PM UTC-8, Christian Hammond wrote:
Hi Brian,
Something to try would be to add:
os.environ['HTTPS'] = 'on'
to htdocs/reviewboard.wsgi.
See if that makes a difference. I noticed this at one point as well. We
need to change things to generate this by default if using https, or find a
beter way to turn it on by default.
Christian
--
Christian Hammond - chi...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com
On Wed, Dec 5, 2012 at 4:31 PM, Brian Lewis *...@brianlewis.us wrote:
Hello All,
I've been racking my brain on this for a couple of days and figured I'd
post here before I refactor my entire setup. Basically what we are doing
is, we have two servers - one is a standard apache web node that acts as a
proxy server and terminates SSL, then we have reviewboard being proxied
behind that.
I've got everything setup and working with the exception of one piece.
I can upload a diff, I can add titles, descriptions, reviewers, etc.
Tracing the requests I can see that https is being returned as the request
URL, HOWEVER, when you go to publish a review, we get a 304 error and the
request URL is a non-https link.
I'm doing the rewriting from the web node directly, with a mod_rewrite
specifically calling out that its proxied (but changing or completely
removing the options doesn't make any difference) For reference, here's
the
rewrite ::
RewriteCond %{HTTPS} off
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R=301,P,PT,L]
When I click on publish, essentially I see two requests (and nothing at
all in the debug logs, etc) The first ::
Request URL:*https://reviewboard.boku.com/reviews/api/review-requests
/189/?api_format=json*
Request Method:GET
Status Code:304 NOT MODIFIED
Request Headersview source
API question: list of files in requests, filtered by path and request date
What would be the best way of getting a list of all reviewed files matching a determined perforce path? I also know I'm after the reviews created after 04/01/12. Should I simply get all the reviews after that date and do any additional filtering client-side? If so, what would be the best way to get all reviews after April *and* the list of files in the reviews? I've used the WEB API before, but I'm clearly not very comfortable with it yet. Thanks, Dado -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en
