Unfortunately this tool isn't smart enough to deal with the assertThat
situation (which has two static imports of a function with the same name).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=172000753
This was a surprisingly involved change. Some of the difficulties included
java.util.Optional purposely not being Serializable (so I had to move a
few Optionals in mapreduce classes to @Nullable) and having to add the Truth
Java8 extension library for assertion support.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171863777
Also fixes the issue that dry run EPP commands were incorrectly being
reported on.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171062984
The concrete implementation of a Metric is not of importance when asserting on the values it contains. Therefore this CL removes Metric<T> as a type parameter of AbstractMetricSubject. As a result the two implementations of the abstract subject can be used on any Metric<Long> and Metric<Distribution>, respectively.
Also migrate to Subject.Factory from deprecated SubjectFactory.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171012012
Users of the client library should be responsible for providing the bindings required. By removing the injectable constructors and named bindings in their parameters, the client library is no longer forcing its users to provide bindings with specific named annotations.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=170490834
*** Reason for rollback ***
Rolling back to fix []
*** Original change description ***
Remove @Inject annotation in StackDriverWriter
StackDriverWriter is provided by java.google.registry.monitoring.whitebox.StackdriverModule. The @Inject annotation in its constructor is not used. It also uses outdated named binding like @Named(stackdriverGcpProject) which causes confusion because that name is not provided anywhere in the code.
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=169931047
StackDriverWriter is provided by java.google.registry.monitoring.whitebox.StackdriverModule. The @Inject annotation in its constructor is not used. It also uses outdated named binding like @Named(stackdriverGcpProject) which causes confusion because that name is not provided anywhere in the code.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=169922096
It turns out that StackdriverWriter uses reflection on the class of
the DistributionFitter instance, so rather than giving it custom
handling for FibonacciFitters, it's easier to turn FibonacciFitter
into a single utility method that takes advantage of existing support
for CustomFitters.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158190147
We want to know how long it's actually taking to process asynchronous
contact/host deletions and DNS refreshes on host renames. This adds
instrumentation. Five metrics are recorded as follows:
* An incrementable metric for each async task processed (split out by
type of task and result).
* Two event metrics for processing time between when a task is enqueued
and when it is processed -- tracked separately for contact/host
deletion and DNS refresh on host rename.
* Two event metrics for batch size every time the two mapreduces are
run (this is usually 0). Tracked separately for contact/host deletion
and DNS refresh on host rename.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157001310
A Fibonacci fitter is useful in situations where you want more precision on the
low end than an ExponentialFitter with exponent base 2 provides without the
hassle of dealing with non-integer boundaries, such as would be created by an
exponential fitter with a base of less than 2. Fibonacci fitters are ideal for
integer metrics that are bounded across a certain range, e.g. integers between 1
and 1,000.
This also cleans up some unit test comments.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=156773367
This CL adds Truth framework subjects to some metrics in the Stackdriver metrics library, in a contrib subpackage. It doesn't deal with gauge metrics, and for event metrics, the assertions can only be that a metric has or does not have a distribution for a particular set of label values. Asserting more fine-grained propositions regarding the distribution will require a distribution subject.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=149112692
Downstream users who use gRPC rather than REST don't want to pull down
rest-related dependencies.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145834701
We're now using java_import_external instead of maven_jar. This allows
us to specify the relationships between jars, thereby allowing us to
eliminate scores of vendor BUILD files that did nothing but re-export
@foo//jar targets, thus addressing the concerns of djhworld on Hacker
News: https://news.ycombinator.com/item?id=12738072
We now have redundant failover mirrors, which is a feature I added to
Bazel 0.4.2 in ed7ced0018
A new standard naming convention is now being used for all Maven repos.
Those names are calculated from the group_artifact name using the
following algorithm that eliminates redundancy:
https://gist.github.com/jart/41bfd977b913c2301627162f1c038e55
The JSR330 dep has been removed from java targets if they also depend
on Dagger, since Dagger always exports JSR330.
Annotation processor dependencies should now be leaner and meaner, by
more appropriately managing what needs to be on the classpath at
runtime. This should trim down the production jar by >1MB. As it stands
currently in the open source world:
- backend_jar_deploy.jar: 50MB
- frontend_jar_deploy.jar: 30MB
- tools_jar_deploy.jar: 45MB
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143487929
This allows separate Bazel projects to reference Nomulus as an external
repository. They can then copy the []
directory structure into their own project and customize the Action
and Module lists for the GAE modules in their own deployment.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=136863886
The Stackdriver API requires that the end time always be greater than the start
time for cumulative metric points.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134396192
This DistributionFitter is suitable for tracking the latency of network calls.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132400538
This is one of a series of CLs adding a new metric type, EventMetric, which
is used for tracking numerical distributions.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132103552
The major changes are using the ExpectedException rule instead of a try/catch
pattern, asserting the message for thrown exceptions, defaulting to JUnit4
unless Mockito is really necessary, and making each test examine one behavior.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=131211346
This CL also adds IncrementableMetric#reset() methods to allow resetting the
value and start timestamp of IncrementableMetrics.
This is necessary because some backends, like Stackdriver, use non-monotonic
changes in cumulative metric values to detect timeseries restarts. Tracking and
re-setting the start timestamp allows users to track mostly monotonic metrics
which may have non-monotonic discontinuities.
See https://cloud.google.com/monitoring/api/ref_v3/rest/v3/TimeSeries#Point for
more details.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=130795229
This change enforces that IncrementableMetrics should only monotonically
increase in value, and adds a new increment() method to increment by one, which is slightly faster than incrementBy (due to a lack of non-negative checking) in the common case that the counter should only be incremented by one.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=130578421
Add additional logic to handle cases when a MetricDescriptor is already defined
on the server, fix an NPE in related code, and add additional tests to ensure
that TimeSeries created from native MetricPoints are well-formed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=130555708
