c/ooni-probe-cli
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
5e868fe043
ooni-probe-cli/go.mod

24 lines
924 B
Modula-2
Raw Normal View History

Use MK v0.10.x, zap legacy GeoIP, build also on Linux (#29) * Gopkg.lock: use MK v0.10.3 * ooni: stop using legacy GeoIP database files * Some yak shaving of Makefile 1. remove now broken commands to download deps 2. also define the CXX cross compiler * chore(dep): migrate from dep to go 1.11+ modules See https://blog.callr.tech/migrating-from-dep-to-go-1.11-modules/ I need this to simplify my life in building for Travis. * Introduce build.sh and repair build In going forward, I believe we don't actually need a Makefile but I didn't want to make such a radical change now. * Another strategy wrt gopath * travis: run regress tests on macOS Closes #30
2019-05-15 14:48:06 +02:00
module github.com/ooni/probe-cli
go 1.12
require (
github.com/alecthomas/kingpin v2.2.6+incompatible
Integrate further with ooni/probe-engine: episode two (#46) * utils/geoip.go: use github.com/ooni/probe-engine Let's start using the engine by rewriting utils/geoip.go to be just a thin wrapper around the engine functionality. * Ready for review * Checkpoint: the im tests are converted Still have some doubts with respect to the variables that are passed to MK via probe-engine. Will double check. * fix(i/c/r/run.go): write the correct logic * nettests: one more comment and also fix a format string * Tweak previous * progress * Fix doofus * better comment * XXX => actionable comment * Add glue to simplify test keys management Making the concept of measurement more abstract in the engine is not feasible because, when submitting a measurement, we need to modify it to update the report ID and the measurement ID. Therefore, returning a serialized measurement is not a good idea. We will keep using a model.Measurement in the engine. Changing model.Measurement.TestKeys's type from a `interface{}` pointing to a well defined data structure to `map[string]interface{}` is a regression because means that we are moving from code that has a clear and defined structure to code that is more complicated to parse and validate. Since we're already suffering havily from the lack of a good schema, I'm not going to make the situation worst by worsening the engine. At least for ndt7 and psiphon, we now have a good schema and I don't want to lose that. However, the current code in this repository is expecting the test keys to be a `map[string]interface{}`. This choice was dictated by the fact that we receive a JSON from Measurement Kit and by the fact that there's not a clear schema. To solve this tension, in this commit I am going to write glue adapter code that makes sure that the TestKeys of a Measurement are converted to `map[string]interface{}`. This will be done using a type cast where possible and JSON serialization and parsing otherwise. In a perfect world, glue is not a good idea, but in a real world it may actually be useful. When all tests in the engine will have a clear Go data structure, we'll then remove the glue and just cast to the proper data structure from `interface{}` where required. * nettests/performance: use probe-engine * go.{mod,sum}: upgrade to latest probe-engine * nettests/middlebox: use ooni/probe-engine * Update to the latest probe-engine * web_connectivity: rewrite to use probe-engine * Cosmetic change suggested by @hellais * nettests/nettests.go: remove unused code * nettests/nettests.go: fix progress * nettests/nettests.go: remove go-measurement-kit code * We don't depend on go-measurement-kit anymore * Improve non-verbose output where possible See also: https://github.com/measurement-kit/measurement-kit/issues/1856 * Make web_connectivity output pleasant * Update to the latest probe-engine * nettests/nettests.go: honour sharing settings * Update to the latest probe-engine * Use log.WithFields for probe-engine * Update go.mod go.sum * Revert "Update go.mod go.sum" This reverts commit 5ecd38d8236f4a4e9b77ddb8e8a0d1e3cdd4b818. * Revert "Revert "Update go.mod go.sum"" This reverts commit 6114b31eca98826112032776bd0feff02d763ecd. * Upgrade ooni/probe-engine * Unset GOPATH before running go build commands * Dockefile: fix linux build by using latest * Update to the latest ooni/probe-engine ``` go get -u github.com/ooni/probe-engine go mod tidy ``` * Repair build
2019-08-15 18:08:43 +02:00
github.com/alecthomas/template v0.0.0-20190718012654-fb15b899a751 // indirect
go.mod go.sum: update all direct dependencies
2019-12-26 17:51:31 +01:00
github.com/alecthomas/units v0.0.0-20190924025748-f65c72e2690d // indirect
Integrate further with ooni/probe-engine: episode two (#46) * utils/geoip.go: use github.com/ooni/probe-engine Let's start using the engine by rewriting utils/geoip.go to be just a thin wrapper around the engine functionality. * Ready for review * Checkpoint: the im tests are converted Still have some doubts with respect to the variables that are passed to MK via probe-engine. Will double check. * fix(i/c/r/run.go): write the correct logic * nettests: one more comment and also fix a format string * Tweak previous * progress * Fix doofus * better comment * XXX => actionable comment * Add glue to simplify test keys management Making the concept of measurement more abstract in the engine is not feasible because, when submitting a measurement, we need to modify it to update the report ID and the measurement ID. Therefore, returning a serialized measurement is not a good idea. We will keep using a model.Measurement in the engine. Changing model.Measurement.TestKeys's type from a `interface{}` pointing to a well defined data structure to `map[string]interface{}` is a regression because means that we are moving from code that has a clear and defined structure to code that is more complicated to parse and validate. Since we're already suffering havily from the lack of a good schema, I'm not going to make the situation worst by worsening the engine. At least for ndt7 and psiphon, we now have a good schema and I don't want to lose that. However, the current code in this repository is expecting the test keys to be a `map[string]interface{}`. This choice was dictated by the fact that we receive a JSON from Measurement Kit and by the fact that there's not a clear schema. To solve this tension, in this commit I am going to write glue adapter code that makes sure that the TestKeys of a Measurement are converted to `map[string]interface{}`. This will be done using a type cast where possible and JSON serialization and parsing otherwise. In a perfect world, glue is not a good idea, but in a real world it may actually be useful. When all tests in the engine will have a clear Go data structure, we'll then remove the glue and just cast to the proper data structure from `interface{}` where required. * nettests/performance: use probe-engine * go.{mod,sum}: upgrade to latest probe-engine * nettests/middlebox: use ooni/probe-engine * Update to the latest probe-engine * web_connectivity: rewrite to use probe-engine * Cosmetic change suggested by @hellais * nettests/nettests.go: remove unused code * nettests/nettests.go: fix progress * nettests/nettests.go: remove go-measurement-kit code * We don't depend on go-measurement-kit anymore * Improve non-verbose output where possible See also: https://github.com/measurement-kit/measurement-kit/issues/1856 * Make web_connectivity output pleasant * Update to the latest probe-engine * nettests/nettests.go: honour sharing settings * Update to the latest probe-engine * Use log.WithFields for probe-engine * Update go.mod go.sum * Revert "Update go.mod go.sum" This reverts commit 5ecd38d8236f4a4e9b77ddb8e8a0d1e3cdd4b818. * Revert "Revert "Update go.mod go.sum"" This reverts commit 6114b31eca98826112032776bd0feff02d763ecd. * Upgrade ooni/probe-engine * Unset GOPATH before running go build commands * Dockefile: fix linux build by using latest * Update to the latest ooni/probe-engine ``` go get -u github.com/ooni/probe-engine go mod tidy ``` * Repair build
2019-08-15 18:08:43 +02:00
github.com/apex/log v1.1.1
go.mod go.sum: update all direct dependencies
2019-12-26 17:51:31 +01:00
github.com/certifi/gocertifi v0.0.0-20191021191039-0944d244cd40 // indirect
Use MK v0.10.x, zap legacy GeoIP, build also on Linux (#29) * Gopkg.lock: use MK v0.10.3 * ooni: stop using legacy GeoIP database files * Some yak shaving of Makefile 1. remove now broken commands to download deps 2. also define the CXX cross compiler * chore(dep): migrate from dep to go 1.11+ modules See https://blog.callr.tech/migrating-from-dep-to-go-1.11-modules/ I need this to simplify my life in building for Travis. * Introduce build.sh and repair build In going forward, I believe we don't actually need a Makefile but I didn't want to make such a radical change now. * Another strategy wrt gopath * travis: run regress tests on macOS Closes #30
2019-05-15 14:48:06 +02:00
github.com/fatih/color v1.7.0
github.com/getsentry/raven-go v0.0.0-20190419175539-919484f041ea
Integrate further with ooni/probe-engine: episode two (#46) * utils/geoip.go: use github.com/ooni/probe-engine Let's start using the engine by rewriting utils/geoip.go to be just a thin wrapper around the engine functionality. * Ready for review * Checkpoint: the im tests are converted Still have some doubts with respect to the variables that are passed to MK via probe-engine. Will double check. * fix(i/c/r/run.go): write the correct logic * nettests: one more comment and also fix a format string * Tweak previous * progress * Fix doofus * better comment * XXX => actionable comment * Add glue to simplify test keys management Making the concept of measurement more abstract in the engine is not feasible because, when submitting a measurement, we need to modify it to update the report ID and the measurement ID. Therefore, returning a serialized measurement is not a good idea. We will keep using a model.Measurement in the engine. Changing model.Measurement.TestKeys's type from a `interface{}` pointing to a well defined data structure to `map[string]interface{}` is a regression because means that we are moving from code that has a clear and defined structure to code that is more complicated to parse and validate. Since we're already suffering havily from the lack of a good schema, I'm not going to make the situation worst by worsening the engine. At least for ndt7 and psiphon, we now have a good schema and I don't want to lose that. However, the current code in this repository is expecting the test keys to be a `map[string]interface{}`. This choice was dictated by the fact that we receive a JSON from Measurement Kit and by the fact that there's not a clear schema. To solve this tension, in this commit I am going to write glue adapter code that makes sure that the TestKeys of a Measurement are converted to `map[string]interface{}`. This will be done using a type cast where possible and JSON serialization and parsing otherwise. In a perfect world, glue is not a good idea, but in a real world it may actually be useful. When all tests in the engine will have a clear Go data structure, we'll then remove the glue and just cast to the proper data structure from `interface{}` where required. * nettests/performance: use probe-engine * go.{mod,sum}: upgrade to latest probe-engine * nettests/middlebox: use ooni/probe-engine * Update to the latest probe-engine * web_connectivity: rewrite to use probe-engine * Cosmetic change suggested by @hellais * nettests/nettests.go: remove unused code * nettests/nettests.go: fix progress * nettests/nettests.go: remove go-measurement-kit code * We don't depend on go-measurement-kit anymore * Improve non-verbose output where possible See also: https://github.com/measurement-kit/measurement-kit/issues/1856 * Make web_connectivity output pleasant * Update to the latest probe-engine * nettests/nettests.go: honour sharing settings * Update to the latest probe-engine * Use log.WithFields for probe-engine * Update go.mod go.sum * Revert "Update go.mod go.sum" This reverts commit 5ecd38d8236f4a4e9b77ddb8e8a0d1e3cdd4b818. * Revert "Revert "Update go.mod go.sum"" This reverts commit 6114b31eca98826112032776bd0feff02d763ecd. * Upgrade ooni/probe-engine * Unset GOPATH before running go build commands * Dockefile: fix linux build by using latest * Update to the latest ooni/probe-engine ``` go get -u github.com/ooni/probe-engine go mod tidy ``` * Repair build
2019-08-15 18:08:43 +02:00
github.com/kr/pty v1.1.8 // indirect
go.mod go.sum: update all direct dependencies
2019-12-26 17:51:31 +01:00
github.com/mattn/go-colorable v0.1.4
github.com/mattn/go-isatty v0.0.11 // indirect
Update to ooni/probe-engine@v0.3.0 1. `go get -u github.com/ooni/probe-engine@v0.3.0` 2. `go mod tidy` 3. fix build failures
2019-12-26 17:48:10 +01:00
github.com/ooni/probe-engine v0.3.0
Use MK v0.10.x, zap legacy GeoIP, build also on Linux (#29) * Gopkg.lock: use MK v0.10.3 * ooni: stop using legacy GeoIP database files * Some yak shaving of Makefile 1. remove now broken commands to download deps 2. also define the CXX cross compiler * chore(dep): migrate from dep to go 1.11+ modules See https://blog.callr.tech/migrating-from-dep-to-go-1.11-modules/ I need this to simplify my life in building for Travis. * Introduce build.sh and repair build In going forward, I believe we don't actually need a Makefile but I didn't want to make such a radical change now. * Another strategy wrt gopath * travis: run regress tests on macOS Closes #30
2019-05-15 14:48:06 +02:00
github.com/pkg/errors v0.8.1
go.mod go.sum: update all direct dependencies
2019-12-26 17:51:31 +01:00
github.com/rubenv/sql-migrate v0.0.0-20191213152630-06338513c237
golang.org/x/sys v0.0.0-20191224085550-c709ea063b76 // indirect
gopkg.in/AlecAivazis/survey.v1 v1.8.7
gopkg.in/mgo.v2 v2.0.0-20190816093944-a6b53ec6cb22 // indirect
upper.io/db.v3 v3.6.3+incompatible
Use MK v0.10.x, zap legacy GeoIP, build also on Linux (#29) * Gopkg.lock: use MK v0.10.3 * ooni: stop using legacy GeoIP database files * Some yak shaving of Makefile 1. remove now broken commands to download deps 2. also define the CXX cross compiler * chore(dep): migrate from dep to go 1.11+ modules See https://blog.callr.tech/migrating-from-dep-to-go-1.11-modules/ I need this to simplify my life in building for Travis. * Introduce build.sh and repair build In going forward, I believe we don't actually need a Makefile but I didn't want to make such a radical change now. * Another strategy wrt gopath * travis: run regress tests on macOS Closes #30
2019-05-15 14:48:06 +02:00
)
Reference in New Issue Copy Permalink