* Add --ignore option when generating namespaces
* use dryrun
* Add dryrun
* Update tests to mock dry run
* Have use_cloud_function as parameter
* Pass dryrun instance
* raise DryRunErrors
* Download files from looker-hub
* Review feedback
* Update generator/lookml.py
Co-authored-by: Sean Rose <1994030+sean-rose@users.noreply.github.com>
---------
Co-authored-by: Sean Rose <1994030+sean-rose@users.noreply.github.com>
The parameter switched out the underlying table to be queried.
However we now have UNIONed tables for every variant of an application,
making the first table contain data from all channels.
Instead we now filter by `normalized_channel` and enforce that filter in explores.
* Add unnested label view
* Add hidden dimension for labeled counter (probably unnecessary)
* Add measures to separate view (broken because of circular dependencies)
* Move unnested view logic into glean ping directly
* Add explore logic to expose join views in explore
* Add test for labeled counter view
* Add description to view
* Break gigantic test for lookml into smaller tests
* Remove extra semicolons and description from view
* Remove duplicate values from explore/view
* Update _to_lookml for API changes
* Add looker suggest explores
* Update tests for suggest explores and new labels
* Use client id as primary key for joins
* Join using document_id as primary key
* Update tests for document id as primary key
* Fix description from rebase
* Address review: longer time period for labels
* Remove document id primary key
* Revert "Remove document id primary key"
This reverts commit 242913c241.
* Sort views in the correct order
* Reduce suggest time to 30 days
Format should be `Explore for <x> ping. <x ping description>`. For
example, for the metrics ping, you would see:
```
Explore for the metrics ping. The metrics ping is intended for all of
the metrics that are explicitly set by the application or are included
in the application's metrics.yaml file (except events). The reported
data is tied to the ping's measurement window, which is the time
between the collection of two metrics ping. Ideally, this window is
expected to be about 24 hours, given that the collection is scheduled
daily at 4AM. Data in the ping_info section of the ping can be used to
infer the length of this window.
```