-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AMS migration: assist and provide feedback (4/n) #461
Comments
Regarding the old collector onion addresses:
This should inform our future actions. |
I've chosen not to merge ooni/probe-android#383 and ooni/probe-ios#397 as explained above. The last piece of work here concerns whether to change ooni/e2etesting. Since we're not using explicit names in ooni/e2etesting for quite some time now, and since we wanted to have periodic testing of our production infra, I would say it's actually fine for us to continue doing so. As such, this issue can now be declared complete. 🥳 🥳 🥳 🥳 |
As discussed with @FedericoCeratto, we want to test the testing infra in github.com/ooni/e2etesting. |
This is the current situation in terms of clients listing only clients with 1% or more measurements:
Computed using this query: SELECT
software_name
, software_version
, platform
, count(*)
FROM
fastpath
WHERE
test_start_time > NOW() - interval '7 day'
AND test_name <> 'ndt'
GROUP BY
software_name
, software_version
, platform
; We exclude |
MK is increasingly less important to us. But we know that we have people running versions of MK compiled by themselves. These persons mainly run NDT tests. To have some confidence we're not breaking their workflows, let us periodically run a MK probe from macOS against the testing infra. This end-to-end test is not very precise, because we are not running the same version they are running and maybe it's not even the same OS and we likely have different dependencies. Yet, it seems a reasonable best effort at ensuring we ain't breaking things too badly. See ooni/backend#461 (comment)
Limit the runs to versions of the legacy probes that have been running non-ndt-measurements in the last seven days. See ooni/backend#461 (comment). Make sure we target both production and testing. As far as testing is concerned, just point to the HTTPS version to ensure that there are no API breakages for now.
* fix: run MK on macOS w/ testing infra only MK is increasingly less important to us. But we know that we have people running versions of MK compiled by themselves. These persons mainly run NDT tests. To have some confidence we're not breaking their workflows, let us periodically run a MK probe from macOS against the testing infra. This end-to-end test is not very precise, because we are not running the same version they are running and maybe it's not even the same OS and we likely have different dependencies. Yet, it seems a reasonable best effort at ensuring we ain't breaking things too badly. See ooni/backend#461 (comment) * fix: tweak legacy probe versions and targets Limit the runs to versions of the legacy probes that have been running non-ndt-measurements in the last seven days. See ooni/backend#461 (comment). Make sure we target both production and testing. As far as testing is concerned, just point to the HTTPS version to ensure that there are no API breakages for now. * fix: tweak probe-cli related checks 1. ensure we build the most relevant versions (unfortunately we still have some people who's running probe-cli 3.0.0 with MK) 2. ensure we test both prod and testing
With the merging of ooni/e2etesting#26, we're really done here. |
Following up from #456. These are the remaining task:
List above poised to shrink/grow as the time progresses. See also #437.
The text was updated successfully, but these errors were encountered: