fcbc77ee784efc133a910290b879e13a18901793: ansible/hgmo: produce bundles for more repositories
Gregory Szorc <gps@mozilla.com> - Tue, 07 Jul 2015 16:21:26 -0700 - rev 361066
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
ansible/hgmo: produce bundles for more repositories Bundles are being added for build/talos, esr38, b2g-inbound, and several project branches that showed up in the top consumers list. As part of this, we now more aggressively schedule bundle creation: every 30 minutes for large repositories. There may be some overlap in production, but the server is beefy and it should be able to handle it.
3b434f336e52683069793bfb0eebbb5eaffaeef6: serverlog: teach repo-totals-by-day to print per-command stats
Gregory Szorc <gps@mozilla.com> - Tue, 07 Jul 2015 16:11:39 -0700 - rev 361065
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
serverlog: teach repo-totals-by-day to print per-command stats Splitting our metrics by command type is useful to see what is driving the load.
9cbdf0e00a7013fda2170025cd45066163487078: serverlog: parse additional hgweb commands from URLs
Gregory Szorc <gps@mozilla.com> - Tue, 07 Jul 2015 15:26:41 -0700 - rev 361064
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
serverlog: parse additional hgweb commands from URLs
4877c008c730c42efc291d83dc156609efb82c1e: serverlog: generate hourly daily aggregates
Gregory Szorc <gps@mozilla.com> - Tue, 07 Jul 2015 15:12:41 -0700 - rev 361063
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
serverlog: generate hourly daily aggregates Why not.
4e97660da01e76165a90308d979cc08a9c124245: ansible/hgmo: remove CRON to aggregate S3 logs
Gregory Szorc <gps@mozilla.com> - Tue, 07 Jul 2015 14:56:27 -0700 - rev 361062
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
ansible/hgmo: remove CRON to aggregate S3 logs The credentials on the host do not have permissions to write to these buckets (and for good reason too). Remove the CRON. The existing entry in the crontab will be removed manually. It isn't worth writing state=absent only to delete it later.
e16fffddfd36b3add42df8381f6080ae9b427f8b: ansible/hg-web: fix typo in CRON definition
Gregory Szorc <gps@mozilla.com> - Tue, 07 Jul 2015 13:39:04 -0700 - rev 361061
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
ansible/hg-web: fix typo in CRON definition
b4e90a985e1be887e0158b8a3bfadc69bc330c49: serverlog: write daily logs with periods as delimiter
Gregory Szorc <gps@mozilla.com> - Tue, 07 Jul 2015 13:38:05 -0700 - rev 361060
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
serverlog: write daily logs with periods as delimiter Mixing - for the type delimiter and the date delimiter is a recipe for failure.
1592cdaaa677e2fd7da52150538c8415463c72b8: serverlog: parse hgweb commands out of URL
Gregory Szorc <gps@mozilla.com> - Tue, 07 Jul 2015 13:34:45 -0700 - rev 361059
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
serverlog: parse hgweb commands out of URL Previously, the repository in the log contained a path component. This made aggregating all traffic belonging to a single repository difficult, as there were multiple keys for a repository. We now do some basic URL parsing and remove hgweb commands from URLs and attribute the request to the proper repository. There is a slight chance we may get a few false positives. We'll have to deploy this and see. Ideally, we should just change serverlog to emit the full relative path to the repository to make this problem go away. But that requires a bunch of work to test different hgweb.wsgi files.
903c12ba77c82c62134aac654688d796209bf7ac: ansible/hg-web: install CRON to generate daily hg logs
Gregory Szorc <gps@mozilla.com> - Tue, 07 Jul 2015 12:53:25 -0700 - rev 361058
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
ansible/hg-web: install CRON to generate daily hg logs This should ideally be part of logrotate. But this was quick and dirty and should work just fine.
fce1db104487b0f4ccbb4568e2adfb1cbc3d5926: Bug 1173441 - Optimize pushhead(tree) revset. r=gps
Nick Alexander <nalexander@mozilla.com> - Wed, 10 Jun 2015 10:40:17 -0700 - rev 361057
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
Bug 1173441 - Optimize pushhead(tree) revset. r=gps This patch adds an index for the specific query, guards against bad pushlog data, and makes the revset lazy. Locally, it performs significantly better than the earlier version. pushhead() without an argument is not performant enough to use locally without this patch; with this patch, it is usable. My use case is finding pushes "close" to tip. Limiting the query to pushes in a certain time range is probably the way to improve the performance.
32e3f6f8a94fae7f626b3588eeb136ddb6e32546: Bug 1173441 - Pre: Add |hg pushlogsync --reset| to wipe local pushlog and start fresh. r=gps
Nick Alexander <nalexander@mozilla.com> - Wed, 10 Jun 2015 10:28:17 -0700 - rev 361056
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
Bug 1173441 - Pre: Add |hg pushlogsync --reset| to wipe local pushlog and start fresh. r=gps
f581b31665954888bdd7732cd8bbb8c5935d186b: serverlog: add script to writing parsed logs into daily files
Gregory Szorc <gps@mozilla.com> - Tue, 07 Jul 2015 10:47:59 -0700 - rev 361055
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
serverlog: add script to writing parsed logs into daily files I plan to use this to backfill logs in production.
603b7a47c0a7985f0fba7db54071ef09b3ba0076: serverlog: add ability to filter dates from parse.py
Gregory Szorc <gps@mozilla.com> - Tue, 07 Jul 2015 10:12:25 -0700 - rev 361054
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
serverlog: add ability to filter dates from parse.py We want to easily extract per-day log files. Rather than create grep chains, it seems easier to build the filtering directly into parse.py. If nothing else, this should make performance slightly better, as we can avoid processing a lot of events that aren't relevant.
af11dc45fc0e343029daea2944262a39c391a712: serverlog: don't parse values unless necessary
Gregory Szorc <gps@mozilla.com> - Tue, 07 Jul 2015 09:34:59 -0700 - rev 361053
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
serverlog: don't parse values unless necessary Parsing strings to numerics is slow. Don't do it unless it is necessary.
15d55fa09cc9c1f29e7f1c305d468c272cf29a16: docs: document how to create new review repositories
Gregory Szorc <gps@mozilla.com> - Tue, 07 Jul 2015 10:03:47 -0700 - rev 361052
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
docs: document how to create new review repositories
d7af1f2c0dd5c9852af6486b6afb5b2faabfcb3f: mozreview: Use a more comprehensible error message when the Bugzilla cookie has expired (bug 1178811). r=smacleod
Mark Cote <mcote@mozilla.com> - Mon, 06 Jul 2015 13:38:32 -0400 - rev 361051
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
mozreview: Use a more comprehensible error message when the Bugzilla cookie has expired (bug 1178811). r=smacleod
91fc0a7dc8ba99542201d6f13e7ba287ad0e13e2: deploy: support for creating review repositories
Gregory Szorc <gps@mozilla.com> - Mon, 06 Jul 2015 17:23:27 -0700 - rev 361050
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
deploy: support for creating review repositories `deploy mozreview-create-repo` can now be used to create new review repositories. For the most part, "it just works." The one observed deficiency is that the bug tracker type of the created repository is not set to "bugzilla." This is because the Review Board web API does not appear to expose this field as a primary field nor allows setting extra_data parameters via the create() API (like review requests supports). This is a minor deficiency and doesn't impact things in production at this time.
4da2bcfbfdf1b199dc11214736bb3514b2eeb4b8: testing: ability to add Review Board repositories via CLI
Gregory Szorc <gps@mozilla.com> - Mon, 06 Jul 2015 17:50:00 -0700 - rev 361049
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
testing: ability to add Review Board repositories via CLI We want to automate the creation of repositories on MozReview. To make this easier, expose a CLI argument for creating repositories inside Review Board.
69d394514f5cb743c3dc6dc263272903b951898c: testing: make username and password configurable
Gregory Szorc <gps@mozilla.com> - Fri, 24 Apr 2015 15:06:08 -0700 - rev 361048
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
testing: make username and password configurable
35c5204a721da9f1a799bc4883b2ab777d05bbd7: reviewboard: prevent reviews with public changesets (bug 1178957); r=smacleod
Gregory Szorc <gps@mozilla.com> - Mon, 06 Jul 2015 15:38:13 -0700 - rev 361047
Push 16998 by rwood@mozilla.com at Mon, 02 May 2016 19:42:03 +0000
reviewboard: prevent reviews with public changesets (bug 1178957); r=smacleod Before this commit, if the working copy was public or the user explicitly requested review of public changesets, we might have attempted to review public changesets. Coupled with the changes to rewrite commits during push, and Mercurial would abort when trying to mutate public changesets. This commit does 2 things. First, it prints a message for each public changeset that is dropped from the request to review. Second, it aborts when there are no non-public changesets left for review and a review cannot be conducted. Users now have a better understanding of what is going on under the covers and they won't get a weird error when trying to push public changesets.
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip