f75448bbdd0a38a92a42904ad0777ac440185fef: testing: serve multiple repositories from commonenv test server
Gregory Szorc <gps@mozilla.com> - Sat, 24 Jan 2015 16:30:08 -0800 - rev 360252
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
testing: serve multiple repositories from commonenv test server We are preparing to use mozreview in the test environment. It creates a Mercurial server that supports multiple repositories as opposed to a single repo server. This patch converts the MozReview test environment to use a server setup that supports multiple repositories. This will make the switchover to mozreview less painful.
3f3ebf296c08789a3e076b693002894d382c492b: testing: ability to replace HGRCPATH in dummyssh
Gregory Szorc <gps@mozilla.com> - Sat, 24 Jan 2015 16:29:46 -0800 - rev 360251
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
testing: ability to replace HGRCPATH in dummyssh When using dummyssh, the HGRCPATH set from the client's environment is likely picked up and used. In complex tests, this may not be desirable, especially if we're testing differences in configurations between client and server. We change the behavior of dummyssh to allow for the existence of an alternate config file (HGSSHHGRCPATH). This allows for clearer separation between client and server configs and better simulates how things work over real SSH.
4ce900443d4b6b2160760c2faa1b59162826aaf2: testing: separate global config in MozReview Mercurial server
Gregory Szorc <gps@mozilla.com> - Sat, 24 Jan 2015 14:42:51 -0800 - rev 360250
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
testing: separate global config in MozReview Mercurial server We refactor the configuration of the Mercurial server in MozReview instances such that the global configuration is different from the web configuration. This simulates how things work in production, which a global hgrc (typically /etc/mercurial/hgrc) provides global defaults and a web config file provides the web configuration. These don't strictly need to be separate files. But it helps keep logic sorted out. And considering Mercurial's behavior of only reading a whitelist of options from web.conf files, it makes sense to keep a wall between them to avoid ambiguity.
b6b821618fe13e819c8bef4c2c1c09655a33c5e0: testing: grab mercurial URL from state, not file
Gregory Szorc <gps@mozilla.com> - Sat, 24 Jan 2015 14:17:01 -0800 - rev 360249
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
testing: grab mercurial URL from state, not file We recently consolidated state for MozReview instances in a JSON file. Rip out the old code utilizing a dedicated file for storing the Mercurial URL.
03af105e5b4ebb3be533244e7c67cd0174074a0a: testing: support grabbing Docker images from environment
Gregory Szorc <gps@mozilla.com> - Sat, 24 Jan 2015 14:03:18 -0800 - rev 360248
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
testing: support grabbing Docker images from environment The mozreview command will now grab Docker images from environment variables. This is groundwork to enable the mozreview command to be used from tests.
3667a2edcb6cbefeab091fc010305598f6f9eb6d: mozreview: Include the Review Board url in commits.published Pulse message (Bug 1125468). r=gps
Steven MacLeod <smacleod@mozilla.com> - Sat, 24 Jan 2015 18:09:49 -0500 - rev 360247
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
mozreview: Include the Review Board url in commits.published Pulse message (Bug 1125468). r=gps
533a56e6df185dd72434a47bf62c4cddb2d4805e: mozreview: Properly setup the Site domain when starting Review Board (Bug 1125468). r=gps
Steven MacLeod <smacleod@mozilla.com> - Fri, 23 Jan 2015 17:02:01 -0500 - rev 360246
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
mozreview: Properly setup the Site domain when starting Review Board (Bug 1125468). r=gps Review Board uses information stored in the Django Site domain field for a few things dealing with urls. We now properly set this to localhost:$HGPORT1 when starting the server. We'll need to modify this if we stop using localhost as the domain.
a3ea41a2e3628f50ec1e0e96c1ea015110dd4589: docs: document boot2docker memory
Gregory Szorc <gps@mozilla.com> - Sat, 24 Jan 2015 10:18:57 -0800 - rev 360245
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
docs: document boot2docker memory
e08ca2467e6d3d19036ece45ad9c98efab1884da: docs: refactor docs around contributing into a Developer Guide
Gregory Szorc <gps@mozilla.com> - Sat, 24 Jan 2015 10:12:26 -0800 - rev 360244
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
docs: refactor docs around contributing into a Developer Guide While we were here, some documentation was updated.
3b3bee82135cf1f1caeab2cf2339b5ee51b244f9: testing: restore http:// downloading of Review Board packages
Gregory Szorc <gps@mozilla.com> - Sat, 24 Jan 2015 09:44:39 -0800 - rev 360243
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
testing: restore http:// downloading of Review Board packages pip is choking on certificates. I suspect https://downloads.reviewboard.org/ still doesn't have their hosting figured out right.
f22c1828238c11368c8f121e69a79627dbc7d17b: testing: issue warning when Docker cert error is encountered
Gregory Szorc <gps@mozilla.com> - Sat, 24 Jan 2015 09:21:02 -0800 - rev 360242
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
testing: issue warning when Docker cert error is encountered This is a very weird issue that seems to reproduce in Python 2.7.9 + docker-py + boot2docker 1.4.1. mcote and I both can reproduce it. The underlying failure is within the ssl C extension. It smells like Docker isn't producing certificates properly or a regression in 2.7.9 or the inability of requests/urllib3 to set up the verification environment properly. Whatever the root cause, this is extremely annoying. We should alert the user.
856aa5bfc5b8e1775c820af2629a590f55fc3bcc: testing: dump review info from review requests; r=smacleod
Gregory Szorc <gps@mozilla.com> - Thu, 22 Jan 2015 14:34:02 -0500 - rev 360241
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
testing: dump review info from review requests; r=smacleod Upcoming tests will verify that reviews and review comments are created properly. We need support for dumping the state of this in YAML. This patch adds that.
f8a98dd80c63db9bfe957158be96de7554d48057: testing: convert output of rbmanage dumpreview to YAML (bug 1124764); r=smacleod
Gregory Szorc <gps@mozilla.com> - Thu, 22 Jan 2015 12:49:09 -0500 - rev 360240
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
testing: convert output of rbmanage dumpreview to YAML (bug 1124764); r=smacleod We were using a custom serializer. We've switched to YAML everywhere else. Use YAML here. We use an OrderedDict and custom serialization behavior of multiline strings to make output more tolerable.
f103ed0e8f00b35a7e25d16e0c2925ff2f4072a4: Bug 1124253. Go back to the old annotateline behavior that links to the file diff, not to the blame for the last revision that changed the line, since the latter is not as useful. r=gps
Boris Zbarsky <bzbarsky@mit.edu> - Thu, 22 Jan 2015 23:33:59 -0500 - rev 360239
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
Bug 1124253. Go back to the old annotateline behavior that links to the file diff, not to the blame for the last revision that changed the line, since the latter is not as useful. r=gps
dc49b2109bf73a0d44824c3716549b1d261616a2: testing: rbmanage command to make a user an admin user
Gregory Szorc <gps@mozilla.com> - Thu, 22 Jan 2015 15:13:54 -0500 - rev 360238
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
testing: rbmanage command to make a user an admin user
7ef52d25d8dcc532aa7fe3c72942813b20257361: mozreview: Include more data in mozreview.commits.published Pulse message (Bug 1124759). r=gps
Steven MacLeod <smacleod@mozilla.com> - Thu, 22 Jan 2015 12:36:38 -0500 - rev 360237
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
mozreview: Include more data in mozreview.commits.published Pulse message (Bug 1124759). r=gps In order to allow commenting on the actual commits consumers need to have the diffset revision for each review request. The new message includes the parent's diffset revision, as well as a diffset revision for each child. A mozreview.commits.published message now contrains the data: { 'parent_review_request_id': <int>, 'parent_diffset_revision': <int>, 'repository_url': <string>, 'commits': [ { 'rev': <string>, 'review_request_id': <int>, 'diffset_revision': <int> }, ... ] }
7de0d66da8d5ed25484e8a2bf4190ee1eee00a96: testing: prefix docker build output with container name
Gregory Szorc <gps@mozilla.com> - Thu, 22 Jan 2015 10:50:17 -0500 - rev 360236
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
testing: prefix docker build output with container name Now that we build images concurrently, we need to prefix the output with the container name so output is attributed to an image.
5bd940851798cbbad34eca77d1621e072bc42bce: testing: fix reference to possibly undefined variable
Gregory Szorc <gps@mozilla.com> - Thu, 22 Jan 2015 10:43:18 -0500 - rev 360235
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
testing: fix reference to possibly undefined variable
b93aebf1d9dd63c1d7688762bd1b77d711bc39c3: testing: remove containers faster
Gregory Szorc <gps@mozilla.com> - Thu, 22 Jan 2015 10:40:33 -0500 - rev 360234
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
testing: remove containers faster When stopping MozReview, we first issued a graceful stop then a remove container. Since we're removing the container, we don't preserve data. So, the time it takes to allow the containers to shut down gracefully is wasted. We switch to just force remove the container, which kills the container. On my machine, stopping containers now takes ~2s instead of ~10s!
fefd66a8f20a99384efe919b9cef0e33ec75c66d: testing: use concurrent.futures to start containers
Gregory Szorc <gps@mozilla.com> - Thu, 22 Jan 2015 10:29:13 -0500 - rev 360233
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
testing: use concurrent.futures to start containers We now start bmodb, bmoweb, and pulse containers concurrently when starting a MozReview instance. This appears to shave a few hundred milliseconds off start.
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip