Silent Update OS Dialogs/Automated testing
If we want to test the Windows service, we need some way to get admin privileges in order to be able to install the service. If the service is already installed on the system, we can use it to install a new version. Otherwise, we need to gain admin privileges. Unfortunately, since Windows does not have something quite equivalent to sudo, so we need to have a way to bootstrap this process in order to get admin privileges.
We have a starttalos.bat script on our talos machines which is a scheduled task with a config like this:
<?xml version="1.0" encoding="UTF-16"?> <Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task"> <RegistrationInfo> <Date>2010-01-12T15:42:53.923</Date> <Author>cltbld</Author> </RegistrationInfo> <Triggers> <LogonTrigger> <Enabled>true</Enabled> <UserId>cltbld</UserId> </LogonTrigger> </Triggers> <Principals> <Principal id="Author"> <UserId>cltbld</UserId> <LogonType>InteractiveToken</LogonType> <RunLevel>HighestAvailable</RunLevel> </Principal> </Principals> <Settings> <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy> <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries> <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries> <AllowHardTerminate>true</AllowHardTerminate> <StartWhenAvailable>false</StartWhenAvailable> <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable> <IdleSettings> <StopOnIdleEnd>true</StopOnIdleEnd> <RestartOnIdle>false</RestartOnIdle> </IdleSettings> <AllowStartOnDemand>true</AllowStartOnDemand> <Enabled>true</Enabled> <Hidden>false</Hidden> <RunOnlyIfIdle>false</RunOnlyIfIdle> <WakeToRun>false</WakeToRun> <ExecutionTimeLimit>P3D</ExecutionTimeLimit> <Priority>7</Priority> </Settings> <Actions Context="Author"> <Exec> <Command>C:\Users\cltbld\Desktop\startTalos.bat</Command> </Exec> </Actions> </Task>
This allows the script to run in privileged mode without the need for somebody to click the UAC dialog. Using a similar mechanism, we could install a known good copy of the service when the machine boots up, and when we're ready to run the tests, the first test can install the new service binary which comes from the build, and then the later tests can go ahead and use the service. This way we can ignore the problem of anything going wrong as part of our test run, since the next time that the machine boots up, it's going to get the known good version of the service.
The downside is that if we need to install a new good version of the service, it's going to be manual work for RelEng. Since the only thing that the known good service is expected to do is to be able to replace itself with the version of the service coming from the binary, I don't expect this problem happening frequently in practice.
In order to automate the process of delivering new good known versions of the service, we're planning to make the installation script download the binary from a known location within the Mozilla build network. We will also download an installation script to enable us to customize the way that the installation works if we need to.