Feature #10259

Automate test for checking whether Tor is up-to-date

Added by anonym 2015-09-26 06:05:46 . Updated 2018-01-18 14:33:17 .

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Test suite
Target version:
Start date:
2015-09-26
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

It could be implemented by removing /etc/apt/preferences, and /etc/apt/sources.list* except /etc/apt/sources.list.d/torproject.list, and then run apt-get update and check the listed installation candidate with apt-cache policy tor.

OTOH, do we want actually want this? Such a scenario would fail whenever a new Tor is realeased => jenkins notifications etc. It might be that we want some external monitoring + notifications for this instead. An alternative would be to tag it in such a way that we only run this scenario at release time. OTOH that is generally too late for actually doing something about it (it’s not as bad for RCs, but bad still).

In fact, even the current manual test is too late. Really this (sanity) check should be done in the release process before the image is built in addition to being part of the Release Manager role, e.g. to check with the Tor people what their release schedule is for the two weeks before the release. That way we will only have to deal with emergency Tor releases on short notice. Actually, it’s similar and highly related to the Tor Browser, since we generally can expect a new version of that one at the same time. Checking the Tor version should be dine in the exact same way, I think.

Subtasks

History

#1 Updated by anonym 2015-09-26 06:06:01

#2 Updated by kytv 2015-09-26 07:27:04

  • Tracker changed from Bug to Feature

#3 Updated by intrigeri 2015-10-03 15:49:54

> It could be implemented by removing /etc/apt/preferences, and /etc/apt/sources.list* except /etc/apt/sources.list.d/torproject.list, and then run apt-get update and check the listed installation candidate with apt-cache policy tor.

There are certainly nicer ways to check what package is in some APT repo. But anyway, IMO “The version of Tor should be the latest stable one” would be better checked using tags in the upstream Git repo.

> OTOH, do we want actually want this? Such a scenario would fail whenever a new Tor is realeased => jenkins notifications etc.

Only RMs should be notified, that is, this should be tested on release branches (stable, testing and devel) only.

> In fact, even the current manual test is too late. Really this (sanity) check should be done in the release process before the image is built in addition to being part of the Release Manager role, e.g. to check with the Tor people what their release schedule is for the two weeks before the release. That way we will only have to deal with emergency Tor releases on short notice. Actually, it’s similar and highly related to the Tor Browser, since we generally can expect a new version of that one at the same time. Checking the Tor version should be dine in the exact same way, I think.

This seems to concur with my proposal above.

(Meta: I’m just throwing some ideas and comments on this pile of new tickets, but I’ll try hard to ignore any follow-up and avoid having a dozen more problems in my head at the same time. Let’s come back to it when we can seriously allocate time to work on these tickets.)

#5 Updated by intrigeri 2018-01-18 14:33:17

  • Type of work changed from Discuss to Code